Qt 5.6.0 released | Hacker News Reader

Qt 5.6.0 released

blog.qt.io

171 pointsronjouch106 comments

I've used Qt many years ago (2007) and I liked the experience, but I had to move away from it because our company decided to go native on all fronts..

For internal tools/prototypes I was using JUCE for my UI needs, which is much smaller in scale that Qt, but it produced very slim executables, was fast and good enough for my needs (plus I loved the API). I still think this a great framework for small UIs and tools, especially if you're working with sound.

Then I took a two years break from C++, moving to full time Objective-C, then Swift 1 and 2, working with and actually enjoying the power of UIKit.. I've developed several UI-heavy apps for iOS and some OSX stuff.

This year I came back to C++ and coincidentally, Qt.

What a nice come back this is. I'm thoroughly enjoying Qt (I'm currently using 5.4). The development is smooth and intuitive, I don't have to spend hours reading documentation and articles, it kind of just flows by itself (not so at all with UIKit )

After trying out many frameworks and kits, If I had to pronounce a verdict for the best cross platform UI framework - then Qt has no competition, both in terms of features and in terms of pleasure.

I hope I can say the same about 5.6, will definitely try it out.

Edit: let me know if you need a Qt dev, as my current project is closing to an end and I would love to continue using Qt . (message codershaman on reddit).

JUCE seems interesting. What kind of difference in executable size are we talking about, approximately?

Pretty big. If you want to use LGPL Qt you need to dynamically link, so deploying will get you around 20 MB of libraries. You can do a command line JUCE app in a few hundred KB, or a GUI app in not much more.

Is the support for static linking good in JUCE, such that you can release non trivial programs in a single binary with reliance only on system libraries that are pretty much guaranteed to be there.

Yes. I only use JUCE on OS X and Windows, but it's all statically linked and looks like it should be on other platforms. On windows you can change the linker settings from /MD to /MT so you aren't even depending on the MSVC redistributables that a completely bare system might not have.

Great! It's nice to be able to easily build and distribute a single executable. Many users are barred from installing software; but can grab single file and run it.

JUCE used to have a feature where the entire library was distributed as one .cpp and one .h file. It made it very easy to distribute JUCE based source code. The make files were very simple. Unfortunately that is no longer supported.

Can I use the new fancy compiler stuff like Lambdas with QT? Does it still require a meta compiler?

Yes and yes

Yes, you can use C++ 11 features with Qt.

In Qt 5.4 I had to add

CONFIG += c++11

to the .pro file.

I haven't used it, but it seems Qt 5.5 supports C++ 14.

You could use C++14 with Qt4 if you wanted. Your choice of standard doesn't really affect Qt much.

Lambdas can be used e.g. with the new signal-slot syntax [1]. And yes, Qt uses the meta compiler, and it's hopefully going to stay that way as moc has a clear positive impact both on features and speed [2].

[1] https://wiki.qt.io/New_Signal_Slot_Syntax

[2] https://woboq.com/blog/moc-myths.html

Wow I had no idea you could put lambdas in place of slots!! Thanks!!

Thanks for the tip on JUCE. I have an audio project I've been wanting to implement for a while, and procrastinating because of ugly audio APIs, JUCE looks just the ticket.

"...but I had to move away from it because our company decided to go native on all fronts.." Wouldn't that be reason to stick or turn to Qt in the first place? Or what am I missing ?

A lot of apps have this non-native QT feel to them. I would guess that's the reason

At that time, Qt was not available on mobile platforms and also the look and feel was very "foreign". Executable size was also a factor at the time I think.

Plus probably some other (political) reasons which I don't know or remember too well..

Qt is easily the best cross-platform UI kit that I have used, especially in combination with Python, which turns it into THE rapid prototyping tool.

For my research I used PyQt/PySide to build lots of UI components for controlling my lab equipment, visualizing my data and running code in an interactive way. While doing this kind of thing using a native toolkit (MFC, GTK) would have been possible, it would probably have been much difficult and time-consuming.

For me, Qt is a great example of beautiful and very good software architecture: Creating a cross-platform UI kit that works on platforms as diverse as Linux, Windows, MacOS, Android and Symbian and integrates well with the peculiar set of features of each platform is a daunting task. Qt as a UI abstraction layer solves this really beautifully, and both the philosophy and the architecture of the code is very well thought through. And in the last five years the developers added many interesting ideas (QML, Javascript support) that compete with and sometimes go beyond what's available in many native toolkits. So if you like reading good code you should have a look at Qt.

> For my research I used PyQt/PySide to build lots of UI components for controlling my lab equipment, visualizing my data and running code in an interactive way. While doing this kind of thing using a native toolkit (MFC, GTK) would have been possible, it would probably have been much difficult and time-consuming.

Neat. What kind of equipment were you controlling with? Is any of your code available? (I'm doing the same these days)

All kinds of lab equipment, mostly interfaced via Visa and/or Gpib. My code is on Github:

https://github.com/adewes/pyview

https://github.com/adewes/python-qubit-setup

For a new project, do you recommend PyQt or PySide?

Stick with PyQt, PySide seems dead.

Yes PySide doesn't even provide Qt 5 bindings, so PyQt remains the best option imho.

PySide development was stalled, and its future was uncertain.

However, PySide is being developed again for Qt5: https://github.com/PySide/pyside2

Not OP but my 2c; PySide is Qt 4.x only, for for that reason I'd recommend PyQt for new projects.

I think it's a real shame the Python + Qt aren't more developed as a solution for creating cross platform mobile apps.

At the moment there are several community efforts but most of them are half baked and have little adoption :(

The popular mobile platforms have never been very friendly to Python. In each case there was some conscious decision to favor specific languages very heavily rather than making it feasible to use different languages. It is hard to see how say PSF could fix this single-handedly.

JVM languages such as Clojure, Scala and Kotlin are friendly to both mobile and javascript platforms.

" While doing this kind of thing using a native toolkit (MFC, GTK) would have been possible, it would probably have been much difficult and time-consuming."

With Lazarus and FreePascal you could do that in minutes.

Docking has improved too: https://wiki.qt.io/New_Features_in_Qt_5.6

  - Allow programmatic resizing of dock widgets
  - Allow dropping dock widgets into floating docks
  - Allow the user to re-arrange tabified docks

I haven't tried it out yet, or seen a demo, but in my previous company we spent some time finding out a solution for docking that mimicks to a degree what Visual Studio did, and we somehow did it, but it's not as good still as Visual Studio.

It was very important for the artists/level builders/scripters to be able to use 3 monitors efficiently (something that the browser lacks in general), and a window spread on three of them is not what they needed.

They really wanted one monitor with say the level (3d map), another monitor would have all assets for preview/selecting, and a third one for additional debugging.

Then when you close, and open again the app it should remember the positions, sizes, etc.

Autodesk Maya/MotionBuilder uses Qt, so if they switch to this version they'll benefit from it.

As an alternative solution, but only in Python (PyQt, PySide) land, there is https://github.com/nucleic/enaml

http://nucleic.github.io/enaml/docs/examples/ex_dock_area.ht...

It's beautiful!

Seems like it's matching Visual Studio :) - https://woboq.com/blog/qdockwidget-changes-in-56.html

Awesome job Qt folks!

Does this work for QtQuick/QML or is it QWidgets only?

I'm not sure, but I would say QWidgets only, e.g. it's QDockWidget

Wow, finally being able to resize dock widgets. I've been searching for this forever, always thinking I was doing something wrong. At least now I know it wasn't really possible. This finally allows me to get my last major UI task out of my todo list :)

Most people think of Qt as a UI framework but it's also an excellent foundation for CLI/server apps, as an alternative to the C++ standard library and/or Boost.

Qt is split into many sub-libraries so you only link to what you need. For example, one of my projects (pushpin.org) uses Qt but only links to the core and network libs; no GUI/X11/etc.

It's also AFAIK one of surprisingly few sources of a utf-8 aware cross-platform string class/libraries for c++.

In addition to this high-level summary, you might also enjoy https://wiki.qt.io/New_Features_in_Qt_5.6 (linked in the blog post, but easy to miss)

My problem with Qt is that it seems like only Python has language bindings that are good long term bet for a project. I'd like to see bindings for Go, Rust, Node.js, and C#/.NET Core with dependable long term commitment to quality. I think there's more a business case to do these than there ever were for Qt Jambi(Swing and SWT existed) or PySide(basically, duplicating PyQt because it's GPL not LGPL).

There are go bindings that are excellent (https://github.com/go-qml/qml). this, combined with the Google Material style kit (http://github.com/papyros/qml-material) results in very simple, clean apps with all the goodness of go.

For me, the only drawback is not being able to expose a go object as a model, involving a bit of back and forth, but the rest is very very clean.

Go does seem to have the best bindings of the platforms I listed, but the reason I put Go on the list is that go-qml hasn't been a commit to the repository in over a year, the mailing list traffic has significantly decreased, and seems to support rather old versions of Qt(though this may be wrong, the docs should be update or made more clear that it means the older version and later).

All very valid points. It would be a shame if the project died. QML and Go just seem to be perfect partners.

Here are non-qml bindings for Go. IT actual qorks quite well. https://github.com/visualfc/goqt

Qt is one of the nicest frameworks I've worked with. I write code that I expect to run (and look roughly the same) on all 3 major plats (win, linux, osx) and Qt does this a lot better than the alternatives.

But what I really appreciate about Qt is the entire system was designed from the ground up by grownups who understand how to deploy software and have it last for over a decade. most of the frameworks today feel like they were developed by kids with little experience to solve limited problems now ,and then fall over as they evolve into something more complex.

It's amazing to me that they maintain binary compatibility across minor version bumps. Anything linked against Qt 5.0 (released 2012) will work with Qt 5.6 without even recompiling.

I also like that you can cast QObjects across dynamic library boundaries.

The high DPI changes sound very promising. I experimented with Qt on Android around 18 months ago and, at the time, had to do a bunch of JNI calls to get an accurate device dpi, and do hacky workarounds, like scaling in the QML, just to get things to look half right.

Qt 5.6 will be on my todo list for further experiments.

Looks like Vulkan support didn't make it to this release.

https://blog.qt.io/blog/2016/02/16/the-qt-company-joins-khro...

Wasn't Vulkan released less than a month ago?

There is a bit of a running joke about Qt 5.6 because it was branched (i.e. feature freeze!) in August of last year.

Woo! It has a bugfix to qt-webkit that I committed. It fixes a canvas.toDataURL issue with PNGs.

I really like Qt and think its an incredible framework overall. Even if you don't use the Qt libraries, QtCreator is one of the best C++ IDEs out there imo (though qmake really sucks and they've been dragging their feet on a proper replacement for years)

The real show stopper for me with Qt is its licensing though. LGPL is a no-go on closed mobile platforms and its commercial license at $350/month is completely unreasonable for smaller developers. Really, the LGPL is a horrible license because of its clause that you must be able to change out the LGPL portion of the software.

Also almost every time there's a thread about Qt I see a bunch of (presumably) web developers start talking about React. In fact, in pretty much every thread talking about any similar framework someone has to mention React. I'm not a web developer and I've only looked at React briefly but I guess I just don't get it. Could someone explain succinctly what the big deal is? I've used Qt a lot -- what do all these people mentioning React want Qt to offer? Why is it brought up so often? Is it really that revolutionary? Almost seems like a cult.

Why not just put your proprietary stuff in a closed-source library and distribute the rest of the source in accordance with the LGPL? What's so horrible about that? Even iOS allows dynamic linking nowadays.

The problem isn't dynamic linking, its the requirement that the end user must be able to re-link a modified version of the LGPL code. So for example, the user should be able to replace the Qt libraries your application links to. On closed platforms like iOS and Android (on Google Play) this isn't really possible. How would your user access your application, modify it and re-sign it?

Previous discussion on HN of the mail app Sparrow and their approach in complying with LGPL on iOS:

https://news.ycombinator.com/item?id=4302517

May be helpful to you.

Its not helpful, they aren't complying with the relinking clause. I don't think there's any way to use LGPL with closed source on mobile app stores.

I'm assuming you didn't read it. I will give you benefit of the doubt since the Sparrow page was pulled after Google acquired them.

Sparrow made available on a website the necessary binaries for the user to relink if they so chose thus complying with the terms of LGPL.

Presumably your closed-source library has an API that you can document. This is how I handle some hardware-access DLLs for proprietary hardware; the distribution gives you the full source for the main program and the non-proprietary hardware access modules, plus the .DLL with the secret sauce for my own hardware. When you run the app, it loads all of the API-compliant DLLs and adds them to the device-selection menu. Anyone can build their own .DLL with the header files provided, or recompile the existing "open" ones if desired.

For an iOS project, you'd provide a link to the GitHub/Sourceforge page or whatever. It's true that the end user would have to get a signing key from Apple to exercise their rights under the LGPL, but IMHO that still meets the spirit of the law. As far as I'm concerned my obligation ends when I provide the code. Some will disagree (hence GPLv3), but the same problem would exist if I had used a language (or targeted a platform) for which there were no free compilers, and nobody seems to have a problem there.

I started playing with QT last week. QML is great.

Is the QT team working on official React API support with JSX ? This will make universal UI development a breeze.

Nothing from the Qt Company itself, but there are some community initiatives around what you're mentioning. This recent mailing list thread mentions a few of them, especially quickflux by community contributor Ben Lau. However, nothing like what you're asking for, QML is clearly not moving in this direction.

- http://lists.qt-project.org/pipermail/development/2016-March...

- https://github.com/benlau/quickflux/

Now, regarding what's actually being done by Qt Company on the UI side, there are the new qtquick controls (currently namespaced to 'labs' as it's still a work in progress), see https://www.youtube.com/watch?v=FqjabvHSiZk and http://blog.qt.io/blog/2015/11/23/qt-quick-controls-re-engin...

Thanks for the links.

The QuickFlux is promising start for the Flux pattern in Qt.

I was thinking more on the lines of React Native [1] like support in Qt.

Essentially, having React render() function backed by Qt Quick Controls?

[1] https://facebook.github.io/react-native/

> QuickFlux is promising start for the Flux pattern in Qt. I was thinking more on the lines of React Native [1] like support in Qt.

I know :) , and I searched for that too when I joined a QML project after working on a React one. So far there's nothing like that, thus the "around" in my comment.

Now, about why no one tried that yet, I'd propose that newcomers (including me) want it but don't know the platform well enough to build it, and experienced C++/Qt-ers could try it, but they don't care about new frontend stuff like React the slightest bit, as they are used to their own thing (which works well too!).

It's just two different technical worlds with different working solutions, and little interest to pick ideas from the other side of the fence. That being said, I'd love to be proven wrong.

I am on the same boat with you. C/Java/JavaScript background. I hope someone cracks this soon.

btw, why you want render() in another framework?

Not exactly the same as React render(), I have started an experimental project to update QML UI by diff:

QSyncable - Synchronize data between models

https://github.com/benlau/qsyncable

p.s In fact, Qt Scene Graph is somehow similar to React. Both of them will only apply the changes to screen. React manipulates the DOM, but Qt manipulates the OpenGL render pipeline.

Will it be worth it/extremely hard to learn C++ just to use Qt? (I always read here and reddit about how hard/inefficient/easy to fail is everything is in C++)

(Eng. background and software dev full time)

C++ is worth knowing, if only superficially, without any regard for Qt.

I am not sure about that. Not in the sense of gaining wisdom as would be in case of, say, Lisp or Haskell -- or even C. C++ is all just nuts and bolts, a more or less coherently implemented collection of paradigms originated in other languages. It is very useful from the practical standpoint, no doubt, but being "worth knowing", "superficially" - not so much IMHO.

Thankfully Qt doesn't go very deep into C++. I've shipped entire GUis without a single template.

Worth it if you need to use a cross-platform desktop framework and don't like java. C++ is most definitely harder to use than many (newer, thus) more modern languages but you will be rewarded by the niceness of Qt.

C++ is certainly difficult, but if your expectations are mainly based on Reddit's opinion of C++, probably the language is not as bad as you think.

If you just want to use Qt, I recommend PyQt / Python. But there are worse ways to learn C++ than via Qt, if learning C++ is your goal.

Is Qt still a good platform for new desktop apps? I often have to choose a framework for new line of business apps on Windows. The choice usually is WPF but I'd prefer Qt. Last time I looked into it it looked a really well thought out framework. And I am one of the weird people who prefer C++ over C#.

My only concern is availability of 3rd part components like data grids, reporting and other widgets. There are many of them for WPF but I am not sure they exist for Qt. Can Qt interact with .NET components?

You can use Qt Charts or Qt 3d. Here is a link to the charts docs

http://doc.qt.io/QtCharts/

As someone who have spent the last six months learning C++ (making the transition from web developer) all I can say is that it'll be hard for me to leave Qt framework. It's very pleasant to work with it (although some corner cases can give you headaches). I'm mostly working with Qt Quick/QML in general (previously I used the widgets but I needed "easy access" to more eye candy effects without spending too much time in code. There's a overhead to pay though).

> As someone who have spent the last six months learning C++ (making the transition from web developer)

Any particular reason why? I know a lot of people doing the opposite (because there are so many more web dev gigs out there).

There are a lot of windows to be washed, and a lot of floors to be scrubbed too.

I want to expand my knowledge. I'm almost done with college and I'm both thrilled and terrified on what will I encounter from here on, there is still a lot to learn.

I'm not as good as many people here I just lurk most of the time, although, I've been doing web development for years, mostly self-taught. I had the opportunity to freelance as well.

Most of my drive to learn C++ is curiosity and the need to be able to write/understand C++ code because I wanted to work with it, I've been meaning to get an Arduino kit too. I'd love to enter the field in C++ as junior dev if possible, at the same time I won't neglect web development if the opportunity is there.

As I said before, I want to expand. I won't just "throw away" web development either. Lastly, I'm not in the US, the job market here is pretty terrible, and have found it hard to look for a place to work. I can work in the U.S, but sadly being both college student + no cash to do much it's pretty hard to pull off.

Can anyone comment on what the uptake of QML is like? Or are most still sticking with the traditional C++/Widgets approach? Are there any major limitations to using pure QML?

I don't know any numbers, but if I'd start a new project, I'd go with C++ logic with QML UI. It automatically steers you to a better application architecture when there's a clear divide between data and representation.

As for limitations, large applications with custom QML may become hard to maintain. I'd expect web development to face the same issue, not sure how they've solved it. Basically refactoring is always a risky operation since you'll find out the breakages only at runtime. For small/medium apps this won't be a problem, but I saw a project with multiple teams on the same codebase for years, and it did cause quite some issues.

Then again, there was no alternative with that project. Widgets wouldn't have been an option at all.

Another plus to this release is they have official VS2015 binaries that you can download, so I don't have to build from source anymore which will save a lot of time.

I'd love to know more about this COIN system that has been released. Jenkins causes a lot of pain for LibreOffice infrastructure devs.

This might be the QT release where you can dock a laptop finally with KDE5 (KF5 or whatever they call it this week) running as https://bugreports.qt.io/browse/QTBUG-42985 seems to be fixed...

Supposedly https://bugreports.qt.io/browse/QTBUG-42985 is fixed which means you can dock a laptop while using KDE.

Can't have a Qt thread without mentioning Nokia Meego, the best phone ever.

I have never used Qt, and I feel like I have missed out. What concise sources would be recommended for someone with a Web development background, in order to start with Qt?

Have a look at the official documentation: https://doc.qt.io/

I've used it in early Qt 4 times to learn Qt myself, but since it's been a while, I can't attest if the documentation is still as good as it was back then, but a quick gloss over it suggests that it is still as extensive. They seem to be focusing the tutorials on their IDE (Qt Creator), but you can also use it with other build systems (preferably CMake) if you prefer the CLI.

I would download the latest Qt with their IDE QtCreator. QtCreator comes default with tons of examples that range from their very early Qt4.x days to the latest Qt5 content. The examples heavily emphasize QML, which I tend to not use for performance reasons, but all of the examples are well documented.

Do you know C++? If so a very fast way to learn is to clone some Qt projects, poke inside and see what makes them tick.

No I am not comfortable with C++ code. I was under the impression that JS along with QML was a viable option, guess I was mistaken.

Take a look at the QML Book if you are particularly interested in the GUI side of things. It is very practical and well written.

http://qmlbook.github.io/

I hope Debian unstable / testing now can move with updating KDE Plasma 5 to the latest version. Looks like they were stuck waiting for Qt update.

I'm actually running Debian testing with Plasma 5.4.3, and Plasma 5 has no hard build deps on Qt 5.6 yet. They also have 5.5.4 in experimental. So it's mostly that the Debian Qt/KDE team has a bit of a conservative approach to updating Plasma in unstable.

I'm using Debian testing too, and noticed the delay. Before, KDE Plasma was moving quite in timely manner in Debian. By now released version is already 5.5 and 5.6 approaching, and Debian still is stuck on the older one. There were some serious Qt bugs[1] which were causing a lot of instability which were fixed in Qt 5.6 so I thought this delay was related.

[1]: like this one: https://bugreports.qt.io/browse/QTBUG-42985

At $350 monthy it's way too expensive. They should consider introducing an indie or individual developer licences at a lower price point.

Isn't the LGPL good enough?

Can I publish dynamically linking Qt app on ios App Store?

They announced a start-up/small business plan [1] of $49/month.

[1] http://www.qt.io/start-up-plan/

Check http://qtweb.net/

Spam? The link says the domain is available...

Not for me, though there appear to be broken images.

This site is temporarily unavailable If you manage this site and have a question about why the site is not available, please contact Domain.com directly.

It was all good until this bit:

"In addition, Pepper plugins (PPAPI), such as Flash, are now supported."

Ugh. :(

Someone downvoted that? Guess they like Qt adding vulnerabilities. :(

You just misunderstood what Qt meant by that line. It's not like they would be shipping Flash with Qt.

Only one question: what changed in the License? Each version of Qt since 4.0 has been getting progressively away from open source.

I'm not sure what you are referring to? It has been LGPLv3 currently was LGPLv2.1 but v2.1 is not recommended anymore so they dropped it. "LGPLv2.1 is an older version and not recommended by the Free Software Foundation for new projects anymore."

It's dual licensed and it is rather prominent everywhere on their webpage that it is a dual licensed Open Sourced / Commercial project. I have found Qt to be very Open/Free friendly, unless you have other evidence to prove other wise?

If your referring to the commercial aspect I'm not sure since I only use the LGPL license.

Seconded. Also, the KDE Free Qt Foundation [1] has slowly extended the reach of their Agreement to include all versions of Qt across all platforms, including most additional modules maintained by Qt Company.

[1] The KDE Free Qt Foundation maintains a legal contract between KDE e.V. and the owners of Qt that mandates that, should Qt not see a new release for longer than 12 months, the last version of Qt be re-licensed under a permissive BSD-style license.

This is a strange accusation, and I'd like to hear what gives you that impression. As far as I know, Qt has been getting more open, with the Free Qt foundation including new platforms and all.

Reply on news.ycombinator.com