31–40 of 108 posts
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).
Earlier quoted context omitted.
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..
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.
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).
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.
Earlier quoted context omitted.
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?
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 d…
This is what made RoboVM go comercial AFAIK, as they could hardly make a living from contributions.
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).
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.
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.
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
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.
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
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 post…
Earlier quoted context omitted.
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