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.

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/) for newer projects. The fact that moc is no longer necessary removes also the main paint point of qt.

I'm just curious of how much force multiplier you can get writing the menus with QML and the game with Qt3d.

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.

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.

What exactly is each 'widget' when you say there are 100+ widgets? Each overall feature, or each Item within the feature?

In my photo editor I have a histogram of how many photos you've taken each day: http://i.imgur.com/7yAYsP9.png

The histogram is actually a ListView, and each delegate is actually not just the bar for each date, but also the background color, the highlight color for the current date, and the date text that's above each bar. Using model updating, it responds nearly instantly even though there are a thousand days in the view, and the source data is a big ol' SQLite query with C++ postprocessing.

I don't know if that's helpful to you, though. Would that count as one widget in your parlance?

ListViews are optimized for display of lists, obviously, so they generally instantiate only visible elements in the view, and delegates do not even undergo geometry negotiation so they're a bit lighter than a regular widget.

Still, if you do visualization or animation, the UI must respond within 1ms in order not to be noticeable, and that's very hard to attain with Qt5.

I doubt people using QML on mobile devices really understand the issue either, since when mobile developers speak of "animations" they generally mean some random transition of the UI itself. Often, the operation is not even performed in the background, but rather simply sequenced (so that the animation appears to be smooth, but the actual delay is completely absorbed by the user). In these scenarios, times up to 250ms/300ms might still be felt "instantaneous" as they're shorter than the transition. For me, it's outrageous.

Also why on earth do they tout being built with autotools as a feature?!

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

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.

[0] https://github.com/papyros/qml-material

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.

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.