12 ms·

Qt 5.7 released

141 points by bpierre 10y ago

symlinkk 10y ago
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.
- lossolo 10y ago
  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.
  - jlarocco 10y ago
    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 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.
- RotsiserMho 10y ago
  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.
  - symlinkk 10y ago
    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 https://woboq.com/blog/verdigris-qt-without-moc.html
    - carewolf 10y ago
      Just don't use slots.
  - defiancedigital 10y ago
    You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...
    - RotsiserMho 10y ago
      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.
- zanny 10y ago
  Theres a neat project in the works: https://github.com/woboq/verdigris 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).
  - VeejayRampay 10y ago
    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).
- coldtea 10y ago
  >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.
- dkersten 10y ago
  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.
  - RotsiserMho 10y ago
    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.
    - dkersten 10y ago
      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.
    - joezydeco 10y ago
      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.
  - Too 10y ago
    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.
- fisherjeff 10y ago
  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.
- slavik81 10y ago
  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.
- jernfrost 10y ago
  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.
- defiancedigital 10y ago
  I'm not disturb by moc. Meta object/programmation is a modern approach of OO.
reddotX 10y ago
JIT support for WinRT, and 64bit ARM platforms in Qt QML, leading to much better QML performance on these platforms +1 for qml perfromance
- smegel 10y ago
  JIT for declarative markup? Has that even been done before?
  - rubber_duck 10y ago
    QML is basically a JavaScript superset ?
    - once-in-a-while 10y ago
      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.
      - sirtaj 10y ago
        Indeed, what kind of fool picks a UI scripting language most likely to already be used by the vast majority of interface designers.
  - CarVac 10y ago
    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.
    - distances 10y ago
      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.
Aissen 10y ago
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://lwn.net/Articles/691131
- rsp1984 10y ago
  Why is the industry anti-LGPLv3? In Layman's terms what are the key differences between LGPL v2.1 and v3?
  - maheart 10y ago
    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 https://en.wikipedia.org/wiki/Tivoization
    - deleted 10y ago
      [deleted]
    - bertit 10y ago
      AFAIK, the reason Apple avoid (L)GPL3 is because of the patents clauses. Not because of the Tivoization
    - zanny 10y ago
      So the LGPL is fulfilling its promise and doing its job by protecting its users from tonka toy hardware they can't control.
      - Matthias247 10y ago
        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.
criddell 10y ago
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).
- darthmaule2 10y ago
  This is pretty amazing to me: http://www.noesisengine.com/ http://www.noesisengine.com/
  - criddell 10y ago
    That looks pretty neat. Have you used it? Can it be set to use native widgets?
    - darthmaule2 10y ago
      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.
- RotsiserMho 10y ago
  hiro (https://gitlab.com/higan/higan/tree/master/hiro https://gitlab.com/higan/higan/tree/master/hiro) by byuu (http://byuu.org 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.
- pjmlp 10y ago
  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.
  - 10y ago
_ZeD_ 10y ago
"This means that all the parts of Qt for Application Development that previously have been available only to commercial users are now available in the Open Source package as well." omg YES! finally! I was waiting for years to use QtCharts!
- mindv0rtex 10y ago
  Just curious - have you ever tried qcustomplot?
steaminghacker 10y ago
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.
- volomike1 10y ago
  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.
Siecje 10y ago
Anyone have a good Qt 5 book? Preferably one that uses QML and Python.
volomike1 10y ago
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.
- defiancedigital 10y ago
  "C++ coder ... often have poor interface skills, anyway" ... troll inside
defiancedigital 10y ago
Any comments about android service support ?
- steaminghacker 10y ago
  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!
wampler 10y ago
TODO: Hello World Exercise #include <QCoreApplication> int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return app.exec(); }

141 points by bpierre 10y ago

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.

lossolo 10y ago
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.
- jlarocco 10y ago
  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 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.
RotsiserMho 10y ago
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.
- symlinkk 10y ago
  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 https://woboq.com/blog/verdigris-qt-without-moc.html
  - carewolf 10y ago
    Just don't use slots.
- defiancedigital 10y ago
  You should consider that c++ lambdas does not offer the same level of connection that signal/slot does (direct,queue,blocking,unique) ...
  - RotsiserMho 10y ago
    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.
zanny 10y ago
Theres a neat project in the works: https://github.com/woboq/verdigris 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).
- VeejayRampay 10y ago
  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).
coldtea 10y ago
>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.
dkersten 10y ago
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.
- RotsiserMho 10y ago
  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.
  - dkersten 10y ago
    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.
  - joezydeco 10y ago
    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.
- Too 10y ago
  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.
fisherjeff 10y ago
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.
slavik81 10y ago
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.
jernfrost 10y ago
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.
defiancedigital 10y ago
I'm not disturb by moc. Meta object/programmation is a modern approach of OO.

reddotX 10y ago

JIT support for WinRT, and 64bit ARM platforms in Qt QML, leading to much better QML performance on these platforms +1 for qml perfromance

smegel 10y ago
JIT for declarative markup? Has that even been done before?
- rubber_duck 10y ago
  QML is basically a JavaScript superset ?
  - once-in-a-while 10y ago
    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.
    - sirtaj 10y ago
      Indeed, what kind of fool picks a UI scripting language most likely to already be used by the vast majority of interface designers.
- CarVac 10y ago
  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.
  - distances 10y ago
    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.

Aissen 10y ago

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://lwn.net/Articles/691131

rsp1984 10y ago
Why is the industry anti-LGPLv3? In Layman's terms what are the key differences between LGPL v2.1 and v3?
- maheart 10y ago
  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 https://en.wikipedia.org/wiki/Tivoization
  - deleted 10y ago
    [deleted]
  - bertit 10y ago
    AFAIK, the reason Apple avoid (L)GPL3 is because of the patents clauses. Not because of the Tivoization
  - zanny 10y ago
    So the LGPL is fulfilling its promise and doing its job by protecting its users from tonka toy hardware they can't control.
    - Matthias247 10y ago
      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.

criddell 10y ago

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).

darthmaule2 10y ago
This is pretty amazing to me: http://www.noesisengine.com/ http://www.noesisengine.com/
- criddell 10y ago
  That looks pretty neat. Have you used it? Can it be set to use native widgets?
  - darthmaule2 10y ago
    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.
RotsiserMho 10y ago
hiro (https://gitlab.com/higan/higan/tree/master/hiro https://gitlab.com/higan/higan/tree/master/hiro) by byuu (http://byuu.org 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.
pjmlp 10y ago
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.
- 10y ago

_ZeD_ 10y ago

"This means that all the parts of Qt for Application Development that previously have been available only to commercial users are now available in the Open Source package as well." omg YES! finally! I was waiting for years to use QtCharts!

mindv0rtex 10y ago
Just curious - have you ever tried qcustomplot?

steaminghacker 10y ago

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.

volomike1 10y ago
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.

Siecje 10y ago

Anyone have a good Qt 5 book? Preferably one that uses QML and Python.

volomike1 10y ago

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.

defiancedigital 10y ago
"C++ coder ... often have poor interface skills, anyway" ... troll inside

defiancedigital 10y ago

Any comments about android service support ?

steaminghacker 10y ago
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!

wampler 10y ago

TODO: Hello World Exercise #include <QCoreApplication> int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return app.exec(); }