Qt 5.7 released
blog.qt.io
blog.qt.io
omg YES! finally! I was waiting for years to use QtCharts!
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.
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.
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.
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.
Good point indeed.
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.
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.
This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.
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.
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.
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.
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.
You don't see this entitlement to free tools in other professions.
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/
(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)
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...
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.
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.
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.
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).
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).
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.
+1 for qml perfromance
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.
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).
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 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.
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 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.
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 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.
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.
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.
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 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.
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.
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.
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.
#include <QCoreApplication>
int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return app.exec(); }
I havent tried the Qt services yet (plan for next week). I hope they work!