Qt 5.7 released(blog.qt.io)
blog.qt.io
Qt 5.7 released
http://blog.qt.io/blog/2016/06/16/qt-5-7-released/
107 comments
Just curious - have you ever tried qcustomplot?
Does anybody have experience with other cross platform GUI toolkits that are still actively developed? It's starting to feel like Qt is going to win it all because they are enduring (and excellent).
libui [1] is a promising new cross platform GUI toolkit. If I need a GUI for a small cross platform desktop app, I will definitely try it.
It uses MIT license, which means there is less headache for commercial applications. It is also more lightweight. I have always felt that Qt has a lot of unnecessary classes. libui has C api, but it would be easy to write a nice c++11 wrapper around it.
[1] https://github.com/andlabs/libui
It uses MIT license, which means there is less headache for commercial applications. It is also more lightweight. I have always felt that Qt has a lot of unnecessary classes. libui has C api, but it would be easy to write a nice c++11 wrapper around it.
[1] https://github.com/andlabs/libui
libui is a very interesting project but I find it still pretty much alpha: good enough for playing around with it, but not quite ready for production. However it is moving fast, so who knows its state in a few months.. Btw, I'm slowly building a python wrapper (1) and accepting contributions!
(1) - https://github.com/joaoventura/pylibui
(1) - https://github.com/joaoventura/pylibui
It has Go wrapper, super easy to use https://github.com/andlabs/ui
Thanks for the pointer. I'm going to watch that project and if it gets to the point where it's settled enough to document, I'll take a deeper look.
This is pretty amazing to me:
http://www.noesisengine.com/
That looks pretty neat. Have you used it? Can it be set to use native widgets?
I have used it, but for an embedded application, so I'm not sure about native widgets as mine were all custom. We ported part of a poor performing WPF application to use NoesisGUI (because NoesisGUI uses Xaml and emulates the WPF api) and had a lot of success with it.
I had a bad experience with Qt on Android as I had to replicate in QML the native widgets and write JNI wrappers myself.
In the end it was more productive to use Java and C++/CX for the views and plain standard C++ for the business logic.
However this was in the 5.4 days and I am looking forward to test it again.
In the end it was more productive to use Java and C++/CX for the views and plain standard C++ for the business logic.
However this was in the 5.4 days and I am looking forward to test it again.
Yes, last time I tested it (several months or a year ago), native look of widgets was great out of the box. One thing I wish - if they had exposed all the QML to C++... i.e. to be able to write only in C++, including UI declarations and callbacks.
I'm not convinced that a single UI is desirable for mobile apps. Sure makes sense to share the business logic if you can, but I feel shared UI code will lead to usability compromises.
hiro (https://gitlab.com/higan/higan/tree/master/hiro) by byuu (http://byuu.org) is similar to libui in that it wraps native controls. It isn't quite stable but it's very interesting. I love the simplicity of the API.
While it doesn't have a similar commercial backing, wxWidgets is still going strong and is quite solid.
I always wondered why, after all these years, the only alternatives that remain are wxWidgets and Qt. It's a very common pattern, multiplatform gui programming! and after all this time, we only have 2 choices..
It's an incredibly fast moving target. Just look at the GTK mess, let alone keeping a wrapper toolkit up to date with other vendors' OS updates. Plus for operating systems like Windows it's not really clear which GUI technology to wrap. All the wrappers I've seen so far wrap the old school Win32 API but many modern applications are written in WPF or WinRT. Supporting all three would be difficult.
Also OS X is a somewhat different beast in terms of human interface guidelines and form layouts so it's really tough to come up with a unified abstraction layer that both supports new operating system features (and UI paradigms) and still provides a reasonably-sized API.
Also OS X is a somewhat different beast in terms of human interface guidelines and form layouts so it's really tough to come up with a unified abstraction layer that both supports new operating system features (and UI paradigms) and still provides a reasonably-sized API.
> All the wrappers I've seen so far wrap the old school Win32 API but many modern applications are written in WPF or WinRT. Supporting all three would be difficult.
Worth noting here that Qt does not wrap the native widgets, it implements its own widgets that are skinned in each platform's native style.
Worth noting here that Qt does not wrap the native widgets, it implements its own widgets that are skinned in each platform's native style.
>Also OS X is a somewhat different beast in terms of human interface guidelines and form layouts so it's really tough to come up with a unified abstraction layer that both supports new operating system features (and UI paradigms) and still provides a reasonably-sized API.
Good point indeed.
Good point indeed.
There are a few other choices for multi-platform GUI programming. Just not too many, and the ones other than wxWidgets and Qt are not so well known a.k.a. mentioned so often on the net. But they exist. There's a Wikipedia page with a list of GUI toolkits. I've tried a few of them briefly, earlier. FLTK (Fast Light Tool Kit) and Fox toolkit are two. Some of them are in C/C++ but some of those have bindings for Python, Ruby, etc. IUP is another that seems interesting, saw it recently. Has bindings only for C and Lua, IIRC. It's from the same Brazilian institute where Lua was created.
Also, the reason not too many have become mainstream (like wx and Qt) is probably largely because it's quite a difficult job to create a new one, even on one OS only [1], unless all you are doing is thinly wrapping an existing native toolkit. I read some about this in a book that goes somewhat into the internals of Qt3 or 4.
[1] and cross-platform is harder still.
Also, the reason not too many have become mainstream (like wx and Qt) is probably largely because it's quite a difficult job to create a new one, even on one OS only [1], unless all you are doing is thinly wrapping an existing native toolkit. I read some about this in a book that goes somewhat into the internals of Qt3 or 4.
[1] and cross-platform is harder still.
IUP has pretty good chicken scheme bindings too. http://wiki.call-cc.org/iup-tutor
Good to know, thanks.
[deleted]
Not exactly the same, but you can use CEF - write your UI in html/css/js.
With LGPLv3, the Qt company is sending a clear signal it's time to pay if you want to use Qt in a device (the industry being clearly anti-(L)GPLv3). It could be the chance for GTK, if they weren't also busy digging their own grave :-/ http://lwn.net/Articles/691131
What's wrong with paying for an extremely high quality GUI toolkit?
Btw. It's very easy to comply LGPLv3 in proprietary project if you want.
1) If you don't modify the Qt library and link dynamically there is no problem whatsoever.
2) If you modify the Qt library or link statically, it's enough to provide modified version of the Qt library and combined object files that make it possible to relink the application to different version.
Industry loves Qt. You either pay a little or spend little extra effort.
Btw. It's very easy to comply LGPLv3 in proprietary project if you want.
1) If you don't modify the Qt library and link dynamically there is no problem whatsoever.
2) If you modify the Qt library or link statically, it's enough to provide modified version of the Qt library and combined object files that make it possible to relink the application to different version.
Industry loves Qt. You either pay a little or spend little extra effort.
Many developers feel entitled to get their tools for free, but expect to be able to charge for their stuff, it seems.
This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.
This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.
Actually, it is "pay upfront" that scares many, I believe. Developers are experimenters - love to play and test many things and in case of commercial success, I think it will be a no-brainier to pay. So I think models such as "pay after your first 10K (or 100K) revenue" work.
Discussions in posts about commercial libraries / tools developers often have extensive discussion about pricing and free alternatives (Threads about SublimeText come to mind). I wonder if the current sad state of developer tooling (stuck in the 70s in many cases) is because of our reluctance to pay for our tools. Would love to hear what others have to say about this.
I belong to a generation that had to pay for its tools.
My first Turbo Pascal for Windows was bought after a few months of saving. Same with other tools.
Even open source, I used to pay for the Walnut Creek CD-Roms.
Nowadays I still buy software tools and do occasional donations.
So I cannot understand how the millenials expect to get their tools for free on one side, but then complain that unless they are selling services or SaaS software no one pays them.
My first Turbo Pascal for Windows was bought after a few months of saving. Same with other tools.
Even open source, I used to pay for the Walnut Creek CD-Roms.
Nowadays I still buy software tools and do occasional donations.
So I cannot understand how the millenials expect to get their tools for free on one side, but then complain that unless they are selling services or SaaS software no one pays them.
> So I cannot understand how the millenials expect to get their tools for free
I'm a (senior) millennial and I'm prepared to pay for tools that are worth it. However, Free (as in freedom) software has come a long way, I won't pay for tooling that is at par or less capable than, with Free software. I think the rise of GPL/Open source - GCC, Linux and Free DBs & languages (and their ecosystems) are to blame; not millennials.
I'm a (senior) millennial and I'm prepared to pay for tools that are worth it. However, Free (as in freedom) software has come a long way, I won't pay for tooling that is at par or less capable than, with Free software. I think the rise of GPL/Open source - GCC, Linux and Free DBs & languages (and their ecosystems) are to blame; not millennials.
Such tools already existed back then, they were called freeware and Public Domain, or came as gifts in magazine listings or tapes.
Also some people would keep on re-installing them past the demo deadline, or crack them, just to avoid paying.
But not on the scale that happens today.
Linux and GCC would not be as developed as they are if it wasn't for the companies that sell hardware and are willing to pay engineer time to improve them.
During GCC early days, most contributors were the ones not wanting to pay for the Solaris SDK, so its development was as fast as Hurd still is today.
Regarding languages, that is why commercial tools get all the nice goodies, no one can make a living of selling improved tooling to FOSS developers.
Hence why many watch a talk from Bret Viktor and are amazed of his presentations, but we already had such tools in 90's, they just had the sin of being commercial.
Also some people would keep on re-installing them past the demo deadline, or crack them, just to avoid paying.
But not on the scale that happens today.
Linux and GCC would not be as developed as they are if it wasn't for the companies that sell hardware and are willing to pay engineer time to improve them.
During GCC early days, most contributors were the ones not wanting to pay for the Solaris SDK, so its development was as fast as Hurd still is today.
Regarding languages, that is why commercial tools get all the nice goodies, no one can make a living of selling improved tooling to FOSS developers.
Hence why many watch a talk from Bret Viktor and are amazed of his presentations, but we already had such tools in 90's, they just had the sin of being commercial.
> Regarding languages, that is why commercial tools get all the nice goodies
I mostly don't need the "nice goodies" - which why I don't but them (and I am prepared to buy when I do, or to show support to the developer. I love JetBrains).
> no one can make a living of selling improved tooling to FOSS developers
Good thing FOSS developers can improve their own tooling; they are developers after all. Freeware and Demoware are hardly comparable to Free & Open Source Software except on price. As a developer, I am empowered when I can fix bugs in my tools and submit a pull request upstream (happened to me 3 times this year alone). What do you do if you run into a bug in Borland Turbo Pascal or QBasic? If you have the energy, submit a bug report and hope it get fixed 4 versions down the line.
I mostly don't need the "nice goodies" - which why I don't but them (and I am prepared to buy when I do, or to show support to the developer. I love JetBrains).
> no one can make a living of selling improved tooling to FOSS developers
Good thing FOSS developers can improve their own tooling; they are developers after all. Freeware and Demoware are hardly comparable to Free & Open Source Software except on price. As a developer, I am empowered when I can fix bugs in my tools and submit a pull request upstream (happened to me 3 times this year alone). What do you do if you run into a bug in Borland Turbo Pascal or QBasic? If you have the energy, submit a bug report and hope it get fixed 4 versions down the line.
I rather spend the hours on the job making the customer happy and off-job hours enjoying my time on earth with family and friends.
I strongly empathize with you on this. It seems that most of us want to believe that the only value add should happen at layer of the software stack we are working on, everything below and above should be a complete (free) commodity.
Well then Qt is great because it's free, you can ship your app using Qt with out paying a nickel and it keeps being free no matter what your revenue. It only costs money if you want to ship your app with different legal terms.
Yeah. Qt is far beyond reasonable, and I categorically can't understand the motivations for people who'd rather pay substantially more, with higher risk, to write their own version.
That's why we can't have nice things...
You'd think their managers would see the benefits of paying a fixed cost instead of doing their own hacking/development.
You are forgetting that section 6 of GPLv3 still applies. That's the so-called "anti-Tivoization clause" that states that you must give the device owner "Installation information", allowing him to install and execute modified forms on this device.
I understand why you would license your software under this if you want to give end users the SW freedoms developers enjoy. I also understand why many makers of safety-critical devices avoid it like the plague.
Case in point, the automotive industry. Coincidentally, the Qt company has in past few years started engaging automotive companies [1][2]. The move to (L)GPLv3 can be valid and has other reasons besides pushing commercial licensing. But you can't say it doesn't have any impact on the industry.
[1] https://www.qt.io/qt-news/qt-company-launches-automotive-sui... [2] Spot the gauge needles and car body models in the announcement http://www.qt.io/qt5-7/
I understand why you would license your software under this if you want to give end users the SW freedoms developers enjoy. I also understand why many makers of safety-critical devices avoid it like the plague.
Case in point, the automotive industry. Coincidentally, the Qt company has in past few years started engaging automotive companies [1][2]. The move to (L)GPLv3 can be valid and has other reasons besides pushing commercial licensing. But you can't say it doesn't have any impact on the industry.
[1] https://www.qt.io/qt-news/qt-company-launches-automotive-sui... [2] Spot the gauge needles and car body models in the announcement http://www.qt.io/qt5-7/
This is also the reason OS X ships with ancient versions of bash, make, and other common GNU tools: those were the last versions to be available under GPLv2.
(Why they ship many of the more optional ones at all instead of embracing external providers like Homebrew or Macport continues to mystify and frustrate me)
(Why they ship many of the more optional ones at all instead of embracing external providers like Homebrew or Macport continues to mystify and frustrate me)
Is it the same reason? Doesn't OS X allow you to replace the system bash?
If someone breaks their init with this replacement, Apple can always say "reinstall the OS". But if you're talking about a car that has crashed that's a different PR problem...
If someone breaks their init with this replacement, Apple can always say "reinstall the OS". But if you're talking about a car that has crashed that's a different PR problem...
Apache 2.0 is not compatible with LGPLv2.1 is the reason back in 2014 and QT has continued to grow during this time.
http://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/
> We also consider locked-down consumer devices using the LGPL’ed version of Qt to be harmful for the Qt ecosystem. ... Because of this, we are now adding LGPL v3 as a licensing option to Qt 5.4 in addition to LGPL v2.1. All modules that are part of Qt 5.3 are currently released under LGPL v2.1, GPL v3 and the commercial license. Starting with Qt 5.4, they will be released under LGPL v2.1, LGPL v3 and the commercial license. ... In Qt 5.4, the new Qt WebEngine module will be released under LGPL v3 in the open source version and under a LGPLv2.1/commercial combination for Qt Enterprise customers. ...
Adding LGPLv3 will also allow us to release a few other add-ons that Digia before intended to make available solely under the enterprise license. ... The first module, called Qt Canvas3D, will give us full WebGL support inside Qt Quick. ... The second module is a lightweight WebView module ... There is a final add-on that will get released under LGPL v3. This module will give native look and feel to the Qt Quick Controls on Android. This module can’t be released under LGPL v2.1, as it has to use code that is licensed under Apache 2.0, a license that is incompatible with LGPL v2.1, but compatible with LGPL v3.
http://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/
> We also consider locked-down consumer devices using the LGPL’ed version of Qt to be harmful for the Qt ecosystem. ... Because of this, we are now adding LGPL v3 as a licensing option to Qt 5.4 in addition to LGPL v2.1. All modules that are part of Qt 5.3 are currently released under LGPL v2.1, GPL v3 and the commercial license. Starting with Qt 5.4, they will be released under LGPL v2.1, LGPL v3 and the commercial license. ... In Qt 5.4, the new Qt WebEngine module will be released under LGPL v3 in the open source version and under a LGPLv2.1/commercial combination for Qt Enterprise customers. ...
Adding LGPLv3 will also allow us to release a few other add-ons that Digia before intended to make available solely under the enterprise license. ... The first module, called Qt Canvas3D, will give us full WebGL support inside Qt Quick. ... The second module is a lightweight WebView module ... There is a final add-on that will get released under LGPL v3. This module will give native look and feel to the Qt Quick Controls on Android. This module can’t be released under LGPL v2.1, as it has to use code that is licensed under Apache 2.0, a license that is incompatible with LGPL v2.1, but compatible with LGPL v3.
If you're fine with dynamic linking, then commercial development is still very much possible (though you lose Qt Charts).
The only major pain is that you have to supply a copy of the Qt Source if requested - the pain being that a link to the official repo is not enough, you have to be in control of the code. However, I would imagine if you gave someone the option of (a) downloading from the website or (b) paying postage and handling for a disc with the same thing, that would satisfy the license.
The only major pain is that you have to supply a copy of the Qt Source if requested - the pain being that a link to the official repo is not enough, you have to be in control of the code. However, I would imagine if you gave someone the option of (a) downloading from the website or (b) paying postage and handling for a disc with the same thing, that would satisfy the license.
> you have to supply a copy of the Qt Source if requested - the pain being that a link to the official repo is not enough
I don't think this this is true. My googling is now failing me as I just get results about linking of libraries, but I remember reading it's enough to point to the source if it's unmodified in your application.
I don't think this this is true. My googling is now failing me as I just get results about linking of libraries, but I remember reading it's enough to point to the source if it's unmodified in your application.
http://www.qt.io/FAQ/#_Toc453700716
The Qt FAQ specifically says that their copy isn't sufficient, but as you say perhaps it only counts if you've made modifications (which would make sense).
The Qt FAQ specifically says that their copy isn't sufficient, but as you say perhaps it only counts if you've made modifications (which would make sense).
Your responsibility is to make sure they can get the code for a certain amount of time after you distributed it to them.
So you can point to the origin source if you feel confident that it will remain available for long enough, and if you know you can provide an alternative way to access it if that site goes down (so just keep a local copy, and if somebody tells you that the link is broken then you just share that copy).
So you can point to the origin source if you feel confident that it will remain available for long enough, and if you know you can provide an alternative way to access it if that site goes down (so just keep a local copy, and if somebody tells you that the link is broken then you just share that copy).
Seems like there should be a company willing to handle that for you. Take $X for for specific hosting and delivery costs up to Y for particular open source projects you've listed, for Z years.
Have you heard of this sweet version control provider called Github? I hear they might provide a solution for this sort of thing, for free.
That doesn't satisfy the legal requirements. First, that repo may go away at some point, and you need it guaranteed, and second, they aren't doing to mail you a physical copy for cost, which is also a stipulation of some of these licenses.
Why is the industry anti-LGPLv3? In Layman's terms what are the key differences between LGPL v2.1 and v3?
The (L)GPL3 disallows Tivoization[1]. Unfortunately, device manufacturers (including Apple) have avoided upgrading to the latest version of certain software (e.g. Bash, Samba, GCC) to avoid the (L)GPL3.
[1] https://en.wikipedia.org/wiki/Tivoization
[1] https://en.wikipedia.org/wiki/Tivoization
So the LGPL is fulfilling its promise and doing its job by protecting its users from tonka toy hardware they can't control.
I don't see any help in protecting auser, if he can see some parts of code and (in case of [L]GPL3 exchange them) but not everything. The "malicous" parts (whatever that means in that context) can still be in the proprietary software parts.
AFAIK, the reason Apple avoid (L)GPL3 is because of the patents clauses. Not because of the Tivoization
[deleted]
> It could be the chance for GTK, if they weren't also busy digging their own grave
They have a fleet of excavators lined up.
Especially for non-X systems, GTK should be considered dead. I kind of liked GTK's C-only approach with simple call backs.
They have a fleet of excavators lined up.
Especially for non-X systems, GTK should be considered dead. I kind of liked GTK's C-only approach with simple call backs.
JIT support for WinRT, and 64bit ARM platforms in Qt QML, leading to much better QML performance on these platforms
+1 for qml perfromance
+1 for qml perfromance
JIT for declarative markup? Has that even been done before?
QML has always had it, as far as I know. It makes for a little pause when loading an application as the logic is compiled. I'm not sure what other markup languages have done this, though.
They do have a Qt Quick compiler though which removes the need to JIT the user interface; maybe next release it'll see the light of day on the open-source side of things.
They do have a Qt Quick compiler though which removes the need to JIT the user interface; maybe next release it'll see the light of day on the open-source side of things.
As far as I understand it's a bit different trade-off: pre-compiled code with no JIT means faster startup, but a bit reduced performance.
QML is basically a JavaScript superset ?
Yeah, it's that bad... If all of your code base is C++, what do you think the mindset is of the main developers? The only compromise they were able to allow themselves to think in was... ECMAScript. Sad.
Indeed, what kind of fool picks a UI scripting language most likely to already be used by the vast majority of interface designers.
I want to like Qt but I hate that it needs moc. Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList" instead of std::vector and std::list.
Theres a neat project in the works:
https://github.com/woboq/verdigris
Unlike Copperspice, the other MOC-less Qt, this one is API compatible with Qt itself, you just include it and drop the MOC and use its functions instead of the original library ones and it can connect to normal Qt data structures.
And like others have said, you can use as few or as many Qt data structures as you want. The problem is that if you end up using Qt IO, you end up getting QStrings and QVariants, which you usually want to keep that way and end up using containers that recognize those types.
If we had a good C++ var type, and a usable string class, there would be an argument to depreciate whats there, but even Qt cannot do utf-8 right (QString is utf-16).
https://github.com/woboq/verdigris
Unlike Copperspice, the other MOC-less Qt, this one is API compatible with Qt itself, you just include it and drop the MOC and use its functions instead of the original library ones and it can connect to normal Qt data structures.
And like others have said, you can use as few or as many Qt data structures as you want. The problem is that if you end up using Qt IO, you end up getting QStrings and QVariants, which you usually want to keep that way and end up using containers that recognize those types.
If we had a good C++ var type, and a usable string class, there would be an argument to depreciate whats there, but even Qt cannot do utf-8 right (QString is utf-16).
For those interested in such things, verdigris comes from the French "vert de gris", which is the colloquial name for copper oxide (translates to green of grey or grey's green).
You can use std as much as you want. Qt doesn't force you to use their containers. Moc is not a problem anymore also, it's more an a myth now than anything else.
That may be technically true, but programs using the std containers have to convert at some point if the data has to show up in the GUI. There may be some really clever ways to avoid a bunch of copying and string conversions, but by default there will be a bit of overhead converting back and forth.
I'm not sure what you mean by "Moc is not a problem anymore, ...". AFAICT, Moc is still used by Qt and is at least still in their documentation. http://doc.qt.io/qt-5/why-moc.html I'm personally not too bothered by Moc and see it as a trade off of using Qt. I'd prefer a cleaner "pure" C++ solution, but I don't know of any GUI toolkits as nice as Qt without Moc.
Qt is still my preferred GUI framework, and I use it from C++, Python, and lately Common Lisp. My biggest complaints are the way it's been increasingly tied to Qt Creator and the focus on Qt Quick and QML.
I'm not sure what you mean by "Moc is not a problem anymore, ...". AFAICT, Moc is still used by Qt and is at least still in their documentation. http://doc.qt.io/qt-5/why-moc.html I'm personally not too bothered by Moc and see it as a trade off of using Qt. I'd prefer a cleaner "pure" C++ solution, but I don't know of any GUI toolkits as nice as Qt without Moc.
Qt is still my preferred GUI framework, and I use it from C++, Python, and lately Common Lisp. My biggest complaints are the way it's been increasingly tied to Qt Creator and the focus on Qt Quick and QML.
I avoided Qt for a long time due to what I'd heard about moc being required. However recent versions support connecting lambdas to slots which is sufficient for my relatively simple application to avoid using moc to set up signals/slots.
Do you have a link that shows how to compile a Qt app without moc? I looked specifically for this and could only find this, which is unofficial and contains a bunch of ugly macros: https://woboq.com/blog/verdigris-qt-without-moc.html
Just don't use slots.
You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...
True, but a lot of that functionality can be gained using boost::signals2 and a simple cross-thread queue. (though some may question the wisdom of trading one dependency for another, I prefer my dependencies decoupled from each other). Still, as I said, lambdas are enough for my simple application.
I actually find their container classes to be much more usable than the STL containers. Obviously that locks you in to Qt, but if you're already using it for a bunch of other stuff in the same application, that seems like a pretty minor concern.
I also don't understand the hate for moc. It's certainly not the most elegant solution, and far from perfect, but it's effective and 99% of the time you can pretty much forget that it's even happening in the background.
I also don't understand the hate for moc. It's certainly not the most elegant solution, and far from perfect, but it's effective and 99% of the time you can pretty much forget that it's even happening in the background.
Serious question because I'm curious: what is the problem with the MOC?
Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.
Sure, its another build step, but so what? I mean, most large complex software has numerous build steps and MOC is pretty straightforward (and if you use QMake or QtCreator, its pretty much invisible to the programmer). I'm trying to understand why people dislike it so much.
It pretends to be c++ but it doesn't support all features and it fails silently during compile time when you don't use it in the exact specific way, problems first arrive at runtime. Some examples of seemingly simple things that just dont work without wrestling or not at all: Objects referring to other types of objects, enum class, 'using' aliases, stdint types, namespaces. Signal slot connections are not compile time type safe. The make process is also broken as sometimes it doesn't understand which files should be rebuilt so you have to force it by removing all generated files.
It pretends to be c++ but it doesn't support all features
It IS C++ though. All of the moc keywords are just macros (that the moc happens to interpret otherwise). signal: is just `#define signal public` and so on. You could compile annotated code without moc without issues.
Signal/slot connections are also compile-time type checked if you use the Qt 5 function pointer syntax: https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html
I won't comment on the rest of what you say, as I don't really know enough about it.
It IS C++ though. All of the moc keywords are just macros (that the moc happens to interpret otherwise). signal: is just `#define signal public` and so on. You could compile annotated code without moc without issues.
Signal/slot connections are also compile-time type checked if you use the Qt 5 function pointer syntax: https://woboq.com/blog/new-signals-slots-syntax-in-qt5.html
I won't comment on the rest of what you say, as I don't really know enough about it.
My problem with it is the fact that it inserts itself in my otherwise standard-conformant C++ code; right in the middle of class declarations. If I decide I want to use another GUI framework I'd have to refactor that code. Most other build steps occur before or after compilation and are far less intrusive. In short, it's too tightly-coupled to application code.
You mean stuff like the "signal" and "slot" declarations in the class definition?
Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
Wouldn't these types of classes be tied to the GUI framework anyway due to the inherited classes, implemented virtual functions, widget classes referenced and so forth? In my experience (having used Qt, GTK, FOX, FLTK and wxWidgets over the years), different GUI frameworks are significantly different in their APIs and how they work, to the point where I think changing existing code from any of these to any other is a very difficult job, with or without moc.
If I decide I want to use another GUI framework I'd have to refactor that code.
If you're already developing in Qt, what do you think the probability of that is?
Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.
If you're already developing in Qt, what do you think the probability of that is?
Personally MOC is worth the price of admission just to have signals transparently marshaled and queued across threads. It makes life incredibly easy.
>Also I don't like that it doesn't use much of the STL - it forces you to use classes like "QVector" and "QList"
Which are quite better designed, more lightweight and better suited to the GUI tasks -- not to mention take less time to compile when used. Of course if you want you can also use STL.
Which are quite better designed, more lightweight and better suited to the GUI tasks -- not to mention take less time to compile when used. Of course if you want you can also use STL.
Originally they made their containers because the standard library implementation was broken or incomplete on many platforms they supported. These days that's not such an issue, but avoiding the standard types allows them to make stronger binary compatibility guarantees.
I think it's a rather nice supplement to the STL. Their containers are optimized quite differently. For instance, all the Qt containers are copy-on-write.
Also, note that QList is not a linked list. QLinkedList is the counterpart to std::list.
I think it's a rather nice supplement to the STL. Their containers are optimized quite differently. For instance, all the Qt containers are copy-on-write.
Also, note that QList is not a linked list. QLinkedList is the counterpart to std::list.
Actually Qt collections are better designed as they work like regular collections in other languages with e.g. copy on write, making regular copies cheap etc. STL is extremely low level and not as well suited for application programming which you typically do with Qt.
I'm not disturb by moc. Meta object/programmation is a modern approach of OO.
Ive been using QtQuick for a while now and the last two weeks i've battled with 5.7RC. So, time to dl the proper release and see if it works any better.
My conclusions are that it's fantastic for desktop apps, but I'm having a lot less success with mobile, specifically Android.
Originally, my plan was to reserve QT for desktop and write the mobile versions separately, whilst sharing the same C++ backend. However, i got tempted to try cross compiling my desktop version for Android.
After a massive battle, it works - a bit. But there's enough that doesn't work that prevents me from making a release just yet (cut & paste is missing!). Looks like I'll have to fill in the blanks myself.
Then Android is always a pig. I'm chewing over whether to recompile QT from source and start hacking it about for Android. This is what Ive had to do with pretty much all the cross platform systems. Android support is always poor and buggy.
On LGPL, I'm fine with it. If you want my QML source code, sure. But for now, I'll keep the backend DLL/.so closed (although I'd like to open that too, when ready). If you want to be able to change the front end and rebuild, I'm ok with that too. in fact, I'll happily document the backend interface for you.
Can we have more Controls.2 QML examples please (most are recycled v1 examples). QtQuick lacks in the tutorial department, although the online docs are good, once you know what you're looking for.
qmake is great, but qtcreator sucks, sorry. Qt widgets is obsolete, QtQuick is the way, once you get over QML.
My conclusions are that it's fantastic for desktop apps, but I'm having a lot less success with mobile, specifically Android.
Originally, my plan was to reserve QT for desktop and write the mobile versions separately, whilst sharing the same C++ backend. However, i got tempted to try cross compiling my desktop version for Android.
After a massive battle, it works - a bit. But there's enough that doesn't work that prevents me from making a release just yet (cut & paste is missing!). Looks like I'll have to fill in the blanks myself.
Then Android is always a pig. I'm chewing over whether to recompile QT from source and start hacking it about for Android. This is what Ive had to do with pretty much all the cross platform systems. Android support is always poor and buggy.
On LGPL, I'm fine with it. If you want my QML source code, sure. But for now, I'll keep the backend DLL/.so closed (although I'd like to open that too, when ready). If you want to be able to change the front end and rebuild, I'm ok with that too. in fact, I'll happily document the backend interface for you.
Can we have more Controls.2 QML examples please (most are recycled v1 examples). QtQuick lacks in the tutorial department, although the online docs are good, once you know what you're looking for.
qmake is great, but qtcreator sucks, sorry. Qt widgets is obsolete, QtQuick is the way, once you get over QML.
I agree that Qt widgets is obsolete with the market -- they're not keeping up with the latest developments in interfaces and should just abandon this.
My question to you is why bother with QtQuick when you can build your interface in Webkit/HTML/CSS/jQuery? With the Webkit angle, then you can integrate file:// and remote content, and can utilize the best interfaces that the web has to offer, which is innovating far faster than QtQuick could ever dream of innovating because there are more web UI coders than there are QtQuick coders. The other great thing with the Webkit approach is that you can hire lower-cost UI coders (who have no background in C++) to do your interface, and debug it using Chrome. The interface would show up in the upper left-hand corner of the browser. They could stub it all out with fake data and get it working completely, and then pass it to you to do the jQuery connectivity to the Qt/C++ DOM injection so that jQuery could call C++ and get results.
However, if installer size is a concern, then yes, QtQuick is the way to go.
My question to you is why bother with QtQuick when you can build your interface in Webkit/HTML/CSS/jQuery? With the Webkit angle, then you can integrate file:// and remote content, and can utilize the best interfaces that the web has to offer, which is innovating far faster than QtQuick could ever dream of innovating because there are more web UI coders than there are QtQuick coders. The other great thing with the Webkit approach is that you can hire lower-cost UI coders (who have no background in C++) to do your interface, and debug it using Chrome. The interface would show up in the upper left-hand corner of the browser. They could stub it all out with fake data and get it working completely, and then pass it to you to do the jQuery connectivity to the Qt/C++ DOM injection so that jQuery could call C++ and get results.
However, if installer size is a concern, then yes, QtQuick is the way to go.
Good question. maybe i don't know the answer. I've been impressed by the way that QML and C++ integrate. I write bits of UI glue JS in QML and these bits call into C++ "magically". I can pass data in and get data back.
This is a lot easier than my JNI battles with Android Java.
I tend to have a lot of backend C++, which performs all the heavy lifting of my apps. I like to make the front UI as thin as possible. QML lets me build things quite fast and i like the way that properties update themselves.
The only real complaint i have with QtQuick/QML is things not working properly on Android. But I'm hoping this situation will improve, and the main reason I'm looking into Controls.2
You say that jquery can call to C++. Where can i find out about this and how would this work on Android.
This is a lot easier than my JNI battles with Android Java.
I tend to have a lot of backend C++, which performs all the heavy lifting of my apps. I like to make the front UI as thin as possible. QML lets me build things quite fast and i like the way that properties update themselves.
The only real complaint i have with QtQuick/QML is things not working properly on Android. But I'm hoping this situation will improve, and the main reason I'm looking into Controls.2
You say that jquery can call to C++. Where can i find out about this and how would this work on Android.
> You say that jquery can call to C++. Where can I find out about this and how would this work on Android?
If you use Qt 4.8, which required that you use Qt Webkit, then you're looking at needing to use the QtWebkit Bridge: http://doc.qt.io/qt-4.8/qtwebkit-bridge.html
If you're using Qt 5.7, which also requires that you use Qt WebEngine, then you're looking at needing to use QWebChannel: http://doc.qt.io/qt-5/qwebchannel.html
They allow you to take a QObject class and then share it with the Webkit DOM as a Javascript object. You can then use Javascript and jQuery to call class methods (only ones you expose) of your Qt/C++ QObject class.
BTW, outside of Qt/C++, on the Mac with Objective C, they provide a way to map the AppDelegate to the Webkit DOM using the windowScriptObject, and ObjC lets you use the native Webkit SDK, rather than having to ship another one with your project.
This is great for desktop applications. Unfortunately for iOS and Android, however, both Qt 4.8's Qt Webkit and Qt 5.7's Qt WebEngine are not supported on those mobile platforms. http://stackoverflow.com/a/30662323/105539 I guess on those, you're stuck with using QtQuick/QML interacting with jQuery and C++, I guess? EDIT: On Android and iOS, you can use Qt WebView within a QML application, which uses the native Webkit on each OS. http://doc.qt.io/qt-5/qtwebview-index.html
If I were to develop for iOS and Android, I'd probably use Apache Cordova until something better comes along: https://en.wikipedia.org/wiki/Apache_Cordova#Supported_platf... . One criticism is that Cordova may be slow in some actions, but phones are getting much faster in every release, negating this trouble.
If you use Qt 4.8, which required that you use Qt Webkit, then you're looking at needing to use the QtWebkit Bridge: http://doc.qt.io/qt-4.8/qtwebkit-bridge.html
If you're using Qt 5.7, which also requires that you use Qt WebEngine, then you're looking at needing to use QWebChannel: http://doc.qt.io/qt-5/qwebchannel.html
They allow you to take a QObject class and then share it with the Webkit DOM as a Javascript object. You can then use Javascript and jQuery to call class methods (only ones you expose) of your Qt/C++ QObject class.
BTW, outside of Qt/C++, on the Mac with Objective C, they provide a way to map the AppDelegate to the Webkit DOM using the windowScriptObject, and ObjC lets you use the native Webkit SDK, rather than having to ship another one with your project.
This is great for desktop applications. Unfortunately for iOS and Android, however, both Qt 4.8's Qt Webkit and Qt 5.7's Qt WebEngine are not supported on those mobile platforms. http://stackoverflow.com/a/30662323/105539 I guess on those, you're stuck with using QtQuick/QML interacting with jQuery and C++, I guess? EDIT: On Android and iOS, you can use Qt WebView within a QML application, which uses the native Webkit on each OS. http://doc.qt.io/qt-5/qtwebview-index.html
If I were to develop for iOS and Android, I'd probably use Apache Cordova until something better comes along: https://en.wikipedia.org/wiki/Apache_Cordova#Supported_platf... . One criticism is that Cordova may be slow in some actions, but phones are getting much faster in every release, negating this trouble.
thanks for this info. i'll checkout WebView, see what it can do.
If you have never taste the limit of Webkit/HTML/CSS/jQuery for client side application, you should stay away of QtQuick criticism.
My understanding is that with Qt, you can keep your own Qt source compiled (and not shared) and use the open source license of Qt, but must dynamically link to the runtimes, list the open source license in your application directory, and list a URL where people can download the source of those Qt runtime DLLs that you are linking.
Also, I found the widgets sub-par to modern interfaces you see on the web today. Let me give you a good example. Do you know those "Check All" checkboxes at the top of grids to check all the checkboxes on the left column of a grid? Yeah, to do that with Qt widgets requires subclassing and intercepting paint events. To me, that's a kludge. So then there's QtQuick. When I compared what I could do in QtQuick compared to what I could do with Webkit/jQuery/CSS, I wondered why be hampered by the limitations of QtQuick when I could just get it all in Webkit/jQuery/CSS. So, I opted to build my stuff in Webkit/jQuery/CSS and use the C++/Webkit bridge that adds an object to the DOM that I can interface with jQuery. The other advantage is that I can hire a web designer (cheaper than a C++ coder (who, often have poor interface skills, anyway)) who knows a bit about jQuery/CSS to design the interfaces for me (they appear in the upper left corner of a web page). We make them web server-less -- they load with file:// handles. Then, I still have the option to IFRAME web content as well as use REST-like APIs (JSON or XML) via jQuery to interact with the web server, or let the C++ interact with the web server over REST-like APIs. The other great reason to use Webkit is because it has a vast library of freely explained techniques for great interface widgets.
There was also a mention about charts. I use Chartjs.org inside my Webkit interface.
The only drawback about going with this Webkit technique is that it does increase the size of your project considerably. On Windows, there's no getting around this. However, on the Mac, the way I got around it was to take my Webkit interface and port it to Objective C/C++ (and try to keep most of it in C++ because I find ObjC quite messy and bizarre, and because I can wrap ObjC stuff in C++). I use a Webkit widget on a form, and it uses the native webkit that comes with the Mac. Therefore, the installer download is tremendously smaller. I then ported the Qt/C++ code into ObjC/C++ -- that wasn't easy, but was manageable for any trained C++ coder.
Also, I found the widgets sub-par to modern interfaces you see on the web today. Let me give you a good example. Do you know those "Check All" checkboxes at the top of grids to check all the checkboxes on the left column of a grid? Yeah, to do that with Qt widgets requires subclassing and intercepting paint events. To me, that's a kludge. So then there's QtQuick. When I compared what I could do in QtQuick compared to what I could do with Webkit/jQuery/CSS, I wondered why be hampered by the limitations of QtQuick when I could just get it all in Webkit/jQuery/CSS. So, I opted to build my stuff in Webkit/jQuery/CSS and use the C++/Webkit bridge that adds an object to the DOM that I can interface with jQuery. The other advantage is that I can hire a web designer (cheaper than a C++ coder (who, often have poor interface skills, anyway)) who knows a bit about jQuery/CSS to design the interfaces for me (they appear in the upper left corner of a web page). We make them web server-less -- they load with file:// handles. Then, I still have the option to IFRAME web content as well as use REST-like APIs (JSON or XML) via jQuery to interact with the web server, or let the C++ interact with the web server over REST-like APIs. The other great reason to use Webkit is because it has a vast library of freely explained techniques for great interface widgets.
There was also a mention about charts. I use Chartjs.org inside my Webkit interface.
The only drawback about going with this Webkit technique is that it does increase the size of your project considerably. On Windows, there's no getting around this. However, on the Mac, the way I got around it was to take my Webkit interface and port it to Objective C/C++ (and try to keep most of it in C++ because I find ObjC quite messy and bizarre, and because I can wrap ObjC stuff in C++). I use a Webkit widget on a form, and it uses the native webkit that comes with the Mac. Therefore, the installer download is tremendously smaller. I then ported the Qt/C++ code into ObjC/C++ -- that wasn't easy, but was manageable for any trained C++ coder.
"C++ coder ... often have poor interface skills, anyway" ... troll inside
I'm not trolling. Someone told me, "Hey, you're a C++ coder. You have like no design skills. I've seen your stuff. It needs work." The investor then brought in a UI expert and wowed me. It was then that I realized, "Wow, I don't have good UI skills." I imagine this is probably the case with many C++ coders. Sorry to offend if you're an awesome UI expert AND a C++ coder.
So, if you "don't have good good UI skills" please stop your comments about QtQuick ...
TODO: Hello World Exercise
#include <QCoreApplication>
int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return app.exec(); }
#include <QCoreApplication>
int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return app.exec(); }
Anyone have a good Qt 5 book? Preferably one that uses QML and Python.
Any comments about android service support ?
Apparently Android services is now in 5.7. This is good news because i need them. I've been working to supercede my Java app with QtQuick and replacing the services was going to be a problem.
I havent tried the Qt services yet (plan for next week). I hope they work!
I havent tried the Qt services yet (plan for next week). I hope they work!
omg YES! finally! I was waiting for years to use QtCharts!