
Qt 5.8 Alpha released - pyprism
http://blog.qt.io/blog/2016/09/05/qt-5-8-alpha-released
======
cm3
> To accommodate this, we have over the last 6 months done significant work on
> our build infrastructure to give our users much more fine grained control
> over the way how Qt is being built. This is what we called the Qt Lite
> Project.

> [...]

> From initial measurements, we expect that you will be able to reduce the
> size of a statically linked Qt Quick application by up to 70% compared to Qt
> 5.6.

Does this mean they fixed static linking in 5.8? It stopped working in 5.7 for
some reason in most projects. With 5.6 it was easy to use cmake scripts to
create statically linked applications when your Qt installation was build
statically. This still worked with qmake projects in 5.7 but not cmake.

I kinda wish I could build a Qt installation that has dynamic libs and static
archives, but it's not possible to select that at configure time.

Stuff either doesn't build or it builds and then still looks for dynamic bits
since 5.7. This was fine in 5.6 AFAIR.

~~~
justinclift
With the static linking in 5.6, did that also include the image format plugins
(eg jpg, bmp, etc)?

~~~
cm3
I'm not exactly sure what you mean, but I think so, since the apps it worked
with did load and save images.

~~~
justinclift
No worries. :)

Putting time into a project recently, and we're going through the process of
migrating from Qt4/Qt5 to Qt5-only. (this is so we can start using Qt5 only
features)

One of the differences between Qt4 and Qt5, is that while Qt4 has all of its
supported image formats inbuilt Qt5 doesn't. It keeps them in separate shared
libraries, which (for non-static applications) need packaging with the rest of
the application. I haven't looked into whether they get compiled in with
static ones though.

It sounds like they might be, which would be useful for us, as people do
request static builds occasionally. :)

~~~
cm3
I'm just a user of Qt applications, so please don't take my comment to be
authoritative. Experiment and conclude.

~~~
justinclift
No worries at all. :)

------
infinite8s
It looks like QML/Qt Quick Controls 2 are moving becoming mobile/embedded
first, and they are recommending desktop apps stick to QtWidgets for native
looking UIs.

~~~
ufo
What language bindings can I use to develop QtWidgets applications without
having to write C++? When I look around it seems that lots of languages only
have bindings for Qt <= 4 or QtQuick.

~~~
jdboyd
You can use pyside2. It isn't considered stable yet though, but I think it
might be soon.

------
justinclift
The docs for it don't seem to be on docs.qt.io. :(

Created a request to add them
([https://bugreports.qt.io/browse/QTBUG-55744](https://bugreports.qt.io/browse/QTBUG-55744)),
to make reading through details of the new modules easier for people.

------
pjmlp
> I think we need more libraries/widgets in order for us to design native
> looking Android/iOS apps.

So still the same "do your own QML mimic of native widgets"?

~~~
dharma1
They are working on providing a set with Qt Quick Controls 2 - the Android
part looks more ready than iOS.

[https://blog.qt.io/blog/2016/06/10/qt-quick-
controls-2-0-a-n...](https://blog.qt.io/blog/2016/06/10/qt-quick-
controls-2-0-a-new-beginning/)

~~~
pjmlp
I know that, but when I used 5.4 the experience was quite bad and I was
quicker to just write the frontend in Java and glue it myself to standard
C++11 than make use of Qt.

So from 5.4. up to 5.8 little seems to have changed from that comment.

Nowadays I just use Native OS UI language + C++ or Xamarin, both are easier
for me to write portable native apps with direct support for native widgets
than using QML.

~~~
dharma1
I think it's improved from 5.4 but yeah if you want native widgets then QML
isn't the solution

