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.
> 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.
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.
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).
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.
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].
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 ?
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..
"...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 ?
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.
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)
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.
" 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.
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.
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?
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.
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.
- 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.
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 :)
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.
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).
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.
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...
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.
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.
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++)
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.
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.
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).
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).
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?
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 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?
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.
111 comments
[ 91.2 ms ] story [ 986 ms ] threadhttps://blog.qt.io/blog/2016/02/16/the-qt-company-joins-khro...
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.
Is the QT team working on official React API support with JSX ? This will make universal UI development a breeze.
- 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...
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/
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.
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.
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).
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.
[1] https://wiki.qt.io/New_Signal_Slot_Syntax
[2] https://woboq.com/blog/moc-myths.html
Plus probably some other (political) reasons which I don't know or remember too well..
[1]: like this one: https://bugreports.qt.io/browse/QTBUG-42985
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.
Neat. What kind of equipment were you controlling with? Is any of your code available? (I'm doing the same these days)
https://github.com/adewes/pyview
https://github.com/adewes/python-qubit-setup
However, PySide is being developed again for Qt5: https://github.com/PySide/pyside2
At the moment there are several community efforts but most of them are half baked and have little adoption :(
With Lazarus and FreePascal you could do that in minutes.
Qt 5.6 will be on my todo list for further experiments.
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.
http://qmlbook.github.io/
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.
[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.
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!
Awesome job Qt folks!
:(
Any particular reason why? I know a lot of people doing the opposite (because there are so many more web dev gigs out there).
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.
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.
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.
(Eng. background and software dev full time)
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.
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?
http://doc.qt.io/QtCharts/
"In addition, Pepper plugins (PPAPI), such as Flash, are now supported."
Ugh. :(
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.
https://news.ycombinator.com/item?id=4302517
May be helpful to you.
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.
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.
[1] http://www.qt.io/start-up-plan/