4 ms·

Qt has evolved fantastically since Digia's acquisition. Just throughout the 5.0 series it has gained incredible feature support for almost anything from full mu

by zanny 11y ago

Qt has evolved fantastically since Digia's acquisition. Just throughout the 5.0 series it has gained incredible feature support for almost anything from full multimedia faculties to websockets to a revitalized 3d rendering engine. And QML is such a breakout success in UI design and just general applications programming compared to the competition - if you have not, you must try coming up with a simple program idea and then try implementing it in QML. Compared to any other tech - GTK, HTML, even Android's ADT the mechanism behind QML is incredibly elegant. I dream of seeing a day in ten years or so where everyone expects right once run everywhere native look and feel applications out of Qt, a toolkit that provides you mechanism to access the full power of your target devices without having to lock yourself into whatever vendors SDK is and thus forcing you to rewrite the same program 5 times for 5 different target devices. Its not there yet - just the other week I was arguing with someone on reddit about the usability of Qt on mobile and conceded it lacks a prebaked gesture support library to easily just do a two finger swipe rather than having to use the multitoucharea type to specify how two finger motion works - but it is getting so very close.

pjmlp 11y ago
The last time I checked, it lacked almost everything in what concerns native mobile widgets, device hardware support, OS events, background services and IPC between apps. Someone made me aware that they are now in yet another reboot for mobile support. Using C++ with standard libraries like Boost plus platform specific language is less effort than re-writing QML for each platform, which still doesn't feel native, while having anyway the work to wrap platform API ourselves.
detaro 11y ago
Does QML have native widgets by now? When I used it last (2 years ago?) you had to make nearly all widgets yourself. Was no problem for our project, which didn't have a native environment to match, but would be an issue for normal applications.
- andresmanz 11y ago
  It does, but I'm not sure if material design is ready now. There is qml-material[0] though, and it's pretty good. But: The last time I checked (maybe 5 or 6 months ago), QML/Qt Quick apps on Android took way too long to launch. I couldn't do anything about it, so haven't used it since then. [0] https://github.com/papyros/qml-material https://github.com/papyros/qml-material
  - jsheard 11y ago
    > QML/Qt Quick apps on Android took way too long to launch. I couldn't do anything about it, so haven't used it since then. Thankfully Qt just announced that their commercial-only components will be added to the open source version soon, including the QML-to-C++ compiler. I haven't had an opportunity to try it myself but they claim it improves startup times significantly.
    - andresmanz 11y ago
      Nice, I didn't know they'd add the compiler. I tried it back then, during the commercial license trial. But it didn't make much of a difference, if any. I remember being in a hurry, though, so maybe I did something wrong and I'd love to give it another try.
  - distances 11y ago
    It's always been slower, but I don't think that can be completely fixed since Qt needs to load all of its libraries. Anyway, it's still possible to optimize the startup to be very usable. You'll want to use a splash screen implemented with minimal UI code (no widgets of any kind yet, just an image with a background). While showing the splash screen, load dynamically a minimal main UI and some critical services -- only the parts that will affect the initial view. Then hide the splash screen. You'll have a small bit of time after the UI becomes visible and before the user will actually use it. You'll want to use this time to load the rest of your services and preload more UI components to avoid the creation lag on UI thread later on. I've done this kind of three-stage loading on Android without technical users even realizing it's not a native app. Would I do it again? Not really if platform native code is an option. There are too many details one has to handle when imitating platform visuals and interaction.
- wentoodeep 11y ago
  Still too slow on android.
donatj 11y ago
I toyed with QML a few months ago. It seemed like it lacked even the most basic of events such as keydown/up in a text area. I didn't get very far and ended up using nw.js instead.
- zanny 11y ago
  All QML visual elements support keyevents: http://doc.qt.io/qt-5/qml-qtquick-keys.html http://doc.qt.io/qt-5/qml-qtquick-keys.html
  - donatj 11y ago
    Hmm, then the documentation is to blame for not making the signaling inheritance clear.
    - deleted 11y ago
      [deleted]
  - donatj 11y ago
    I am currently toying with it again and none of those signals appear to be working on http://doc.qt.io/qt-5/qml-qtquick-controls-textarea.html#signals http://doc.qt.io/qt-5/qml-qtquick-controls-textarea.html#sig...
tenfingers 11y ago
I wished Qt just split into a different widget set for mobile. The interaction behavior is significantly different that attempting to reuse the same UI for both mobile and desktop will result in a terrible experience on both. Likewise, QML is just plainly useless on the desktop, and much slower to booth. Unfortunately, the performance regression in Qt5 is there also if you don't use it, and that shouldn't be. Qt5 being slower than Qt4 is the main reason I've been moving slowly towards copperspice (http://www.copperspice.com/ http://www.copperspice.com/) for newer projects. The fact that moc is no longer necessary removes also the main paint point of qt.
- CarVac 11y ago
  How exactly is QML and Qt5 slower? It's quick to start and UI actions are immediate and smooth. Forgive me for not knowing, since I've never used Qt Widgets before. I'm writing a desktop app with QML and it's fast and smooth thanks to the OpenGL acceleration.
  - tenfingers 11y ago
    If you have a classical desktop interface where you reach 100+ widgets (which sounds like a lot but is easily reachable with just a toolbar, some buttons and a form), the difference is noticeable when interacting even on recent hardware (i5+). For example, since I work in visualization, I often tie data widgets to the GL canvas in order to provide realtime feedback. I also use Qt5 in order to provide keyboard accelerators. With QT5 the rendering latency grew so high that I couldn't provide realtime feedback anymore, and I had to batch requests (and finally reverted to Qt4). Incidentally Qt5 widgets can be used in a GL context directly, but are way too slow to render and manage events to be used consistently at 60 fps (they're not designed for that, so their scope in this sense is not as broad as it can really be). It's actually faster to give them their own GL context in order not to interfere with your pipeline, which kinds-of defeat the point. I've also found that the additional JS glue doesn't provide any benefit unless you go entirely QML.
    - CarVac 11y ago
IshKebab 11y ago
I'm not sure I'd call QML a "breakout success". There are definitely huge issues with it, notably: * It's quite incomplete. There are a lot of things you just can't do in it. For example try doing a widget of the kind you'd use for compilation output in an IDE. There is a multiline text editor widget, but the only efficient operation is appending text - you can't remove the first line for example. * If you decide you will write your own QML widget (e.g. for the compilation output), you find that there is no way to render text! The scene graph text nodes are still private. * You have to use Javascript (ugh) * There's quite a lot of friction converting C++ types to Javascript and vice versa. Especially with lists and arrays. For example when you access a C++ array from Javascript it has to copy the whole array into a native Javascript array, and then modifications are lost. * The scope of files and IDs is quite messy - parents can refer to their children's IDs, so there is no concept of data encapsulation. To be honest I still haven't totally worked out the rules, but they're a mess in any case. * Dynamically creating dialogs and UI elements is a bit of a mess. The "standard" way to have dialogs is (more or less) to create all dialogs the program needs at startup and hide them all until needed. Obviously that doesn't scale well for things like tooltips. Creating them dynamically is rather painful (especially when there are no examples for how to do it!) QML is definitely a nice idea, but I think they need to give it a third try, and probably not use Javascript.
- royjacobs 11y ago
  What tripped me up when I did some QML is that interop of lists between C++ and QML is usually shown in tutorials as going via QQmlListProperty but that is actually not what it's supposed to be used for, resulting in subtle memory leaks and crashes when ownership gets mixed up. Additionally, it only JUST got a TreeView (Qt 5.5 I believe) and a lot of additional widgets you would need to implement a regular desktop app are just missing.
  - IshKebab 11y ago
    Yeah me too. Took me ages to realise you should use QAbstractListModel.

by zanny 11y ago

pjmlp 11y ago

The last time I checked, it lacked almost everything in what concerns native mobile widgets, device hardware support, OS events, background services and IPC between apps. Someone made me aware that they are now in yet another reboot for mobile support. Using C++ with standard libraries like Boost plus platform specific language is less effort than re-writing QML for each platform, which still doesn't feel native, while having anyway the work to wrap platform API ourselves.

detaro 11y ago

Does QML have native widgets by now? When I used it last (2 years ago?) you had to make nearly all widgets yourself. Was no problem for our project, which didn't have a native environment to match, but would be an issue for normal applications.

andresmanz 11y ago
It does, but I'm not sure if material design is ready now. There is qml-material[0] though, and it's pretty good. But: The last time I checked (maybe 5 or 6 months ago), QML/Qt Quick apps on Android took way too long to launch. I couldn't do anything about it, so haven't used it since then. [0] https://github.com/papyros/qml-material https://github.com/papyros/qml-material
- jsheard 11y ago
  > QML/Qt Quick apps on Android took way too long to launch. I couldn't do anything about it, so haven't used it since then. Thankfully Qt just announced that their commercial-only components will be added to the open source version soon, including the QML-to-C++ compiler. I haven't had an opportunity to try it myself but they claim it improves startup times significantly.
  - andresmanz 11y ago
    Nice, I didn't know they'd add the compiler. I tried it back then, during the commercial license trial. But it didn't make much of a difference, if any. I remember being in a hurry, though, so maybe I did something wrong and I'd love to give it another try.
- distances 11y ago
  It's always been slower, but I don't think that can be completely fixed since Qt needs to load all of its libraries. Anyway, it's still possible to optimize the startup to be very usable. You'll want to use a splash screen implemented with minimal UI code (no widgets of any kind yet, just an image with a background). While showing the splash screen, load dynamically a minimal main UI and some critical services -- only the parts that will affect the initial view. Then hide the splash screen. You'll have a small bit of time after the UI becomes visible and before the user will actually use it. You'll want to use this time to load the rest of your services and preload more UI components to avoid the creation lag on UI thread later on. I've done this kind of three-stage loading on Android without technical users even realizing it's not a native app. Would I do it again? Not really if platform native code is an option. There are too many details one has to handle when imitating platform visuals and interaction.
wentoodeep 11y ago
Still too slow on android.

donatj 11y ago

I toyed with QML a few months ago. It seemed like it lacked even the most basic of events such as keydown/up in a text area. I didn't get very far and ended up using nw.js instead.

zanny 11y ago
All QML visual elements support keyevents: http://doc.qt.io/qt-5/qml-qtquick-keys.html http://doc.qt.io/qt-5/qml-qtquick-keys.html
- donatj 11y ago
  Hmm, then the documentation is to blame for not making the signaling inheritance clear.
  - deleted 11y ago
    [deleted]
- donatj 11y ago
  I am currently toying with it again and none of those signals appear to be working on http://doc.qt.io/qt-5/qml-qtquick-controls-textarea.html#signals http://doc.qt.io/qt-5/qml-qtquick-controls-textarea.html#sig...

tenfingers 11y ago

I wished Qt just split into a different widget set for mobile. The interaction behavior is significantly different that attempting to reuse the same UI for both mobile and desktop will result in a terrible experience on both. Likewise, QML is just plainly useless on the desktop, and much slower to booth. Unfortunately, the performance regression in Qt5 is there also if you don't use it, and that shouldn't be. Qt5 being slower than Qt4 is the main reason I've been moving slowly towards copperspice (http://www.copperspice.com/ http://www.copperspice.com/) for newer projects. The fact that moc is no longer necessary removes also the main paint point of qt.

CarVac 11y ago
How exactly is QML and Qt5 slower? It's quick to start and UI actions are immediate and smooth. Forgive me for not knowing, since I've never used Qt Widgets before. I'm writing a desktop app with QML and it's fast and smooth thanks to the OpenGL acceleration.
- tenfingers 11y ago
  If you have a classical desktop interface where you reach 100+ widgets (which sounds like a lot but is easily reachable with just a toolbar, some buttons and a form), the difference is noticeable when interacting even on recent hardware (i5+). For example, since I work in visualization, I often tie data widgets to the GL canvas in order to provide realtime feedback. I also use Qt5 in order to provide keyboard accelerators. With QT5 the rendering latency grew so high that I couldn't provide realtime feedback anymore, and I had to batch requests (and finally reverted to Qt4). Incidentally Qt5 widgets can be used in a GL context directly, but are way too slow to render and manage events to be used consistently at 60 fps (they're not designed for that, so their scope in this sense is not as broad as it can really be). It's actually faster to give them their own GL context in order not to interfere with your pipeline, which kinds-of defeat the point. I've also found that the additional JS glue doesn't provide any benefit unless you go entirely QML.
  - CarVac 11y ago

IshKebab 11y ago

I'm not sure I'd call QML a "breakout success". There are definitely huge issues with it, notably: * It's quite incomplete. There are a lot of things you just can't do in it. For example try doing a widget of the kind you'd use for compilation output in an IDE. There is a multiline text editor widget, but the only efficient operation is appending text - you can't remove the first line for example. * If you decide you will write your own QML widget (e.g. for the compilation output), you find that there is no way to render text! The scene graph text nodes are still private. * You have to use Javascript (ugh) * There's quite a lot of friction converting C++ types to Javascript and vice versa. Especially with lists and arrays. For example when you access a C++ array from Javascript it has to copy the whole array into a native Javascript array, and then modifications are lost. * The scope of files and IDs is quite messy - parents can refer to their children's IDs, so there is no concept of data encapsulation. To be honest I still haven't totally worked out the rules, but they're a mess in any case. * Dynamically creating dialogs and UI elements is a bit of a mess. The "standard" way to have dialogs is (more or less) to create all dialogs the program needs at startup and hide them all until needed. Obviously that doesn't scale well for things like tooltips. Creating them dynamically is rather painful (especially when there are no examples for how to do it!) QML is definitely a nice idea, but I think they need to give it a third try, and probably not use Javascript.

royjacobs 11y ago
What tripped me up when I did some QML is that interop of lists between C++ and QML is usually shown in tutorials as going via QQmlListProperty but that is actually not what it's supposed to be used for, resulting in subtle memory leaks and crashes when ownership gets mixed up. Additionally, it only JUST got a TreeView (Qt 5.5 I believe) and a lot of additional widgets you would need to implement a regular desktop app are just missing.
- IshKebab 11y ago
  Yeah me too. Took me ages to realise you should use QAbstractListModel.