Qt 5.8 Alpha released | Hacker News Reader

Qt 5.8 Alpha released

blog.qt.io

111 pointspyprism27 comments

> 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.

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

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

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. :)

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

No worries at all. :)

Well, I just made a static build of a Qt 5.7 project that required the SVG image format plugin, so it's definitely possible. In qmake projects, it all happens automatically if you specify the plugins you use in the QTPLUGINS variable. In my case, I needed to add 'svg' to the QT variable. For non-qmake projects, I think you have to add Q_IMPORT_PLUGIN() macros to the source code of your program to "load" the statically linked plugins.

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.

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.

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

PyQt is rock solid.

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), to make reading through details of the new modules easier for people.

> 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"?

I don't want iOS look at all

Most iOS users using iOS apps want, though.

Most iOS user or Android users don't know and don't care, if we're being honest. If you said "power users" or "developers", then it's a different story. I long for the days of the iOS 4.2 UI, but that's just me preferring distinctive widgets over a flat sea of mostly-white indistinguishable things.

Personally, I would rather that apps follow the paradiggem (int.) established for the platform, so that there are fewer surprises. So, if you're on OS X, look and feel like an OS X app, ditto for IOS.

QT looks and feels like QT and takes a lot of it's cues from Windows (near as I can tell) so no QT app feels like it belongs on a Mac at all.

I wasn't aware you can write apps using QuickTime ;)

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...

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.

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

Is it just me, or is there some overlap and possibly short-lived components one shouldn't invest time in (ala Silverlight and XAML)? I don't know why there's QML and QtQuick.

QML is perhaps the best current option for cross-platform desktop application creation and for embedded devices with custom UI. For mobile apps it's debatable if QML makes as much sense.

Can you tell me why do you feel QML is superior to Qt Widgets for desktop applications?

I tried QtQuick 1 and was underwhelmed (so much glue code to link C++ and QML; the awkwardness of JS without the huge amount of libraries that save your day in web development). In the last couple of years I have seen a lot of renewed hype about QML but I keep wondering what it's buying you over the traditional widgets in non-embedded envs (where you might want to profit from OpenGL acceleration for performance reasons).

Am I missing something? I would love to love QML, as I love Qt and I see that widgets are clearly on their way out...

My experience is indeed more on the embedded and mobile side of things, where hardware acceleration and animations are indeed a major selling point.

I'd let others with more experience on desktop QML vs. widgets to judge their respective strengths, my comment was more about Qt vs. non-Qt frameworks. That makes QML the topic as it's currently the main UI development story for Qt.

Are you sure? I'm building a cross platform desktop application at the moment. I briefly considered QML, but decided against it because I care about high-DPI support and native look & feel on Windows, and it seems like Qt Quick Controls 1 doesn't provide the former and Qt Quick Controls 2 doesn't provide the latter.

Because of this, I'm a bit disappointed that Qt 5.8 alpha doesn't have anything interesting for Qt Widgets users. Qt Widgets is the best cross-platform UI framework out there, but Qt Quick is, at least from my perspective, a bit mediocre.

I don't have much experience with Qt, although I had done a few toy applications since the early KDE 2.0 days with it.

The last attempt was a small mobile app for Android/WP that I ended up rewriting in Java,C++/CX + C++11, because of the issues I had with Qt 5.4.

However I still follow the announcements and get the feeling that they are trying to re-purpose Qt in the same way that JavaFX, WPF/XAML and mobile OS UI stacks have done, but it is still catching up with their feature sets.

Reply on news.ycombinator.com