> The design direction is because QML is easier to develop with, more modern, > and based on OpenGL. Widgets don't have that and will never be as efficient. > Therefore, the effort is directed towards the technology that has the > potential > to make interfaces for 2017-2020.
Unfortunately that means there are now 4 completely separate UI stacks to maintain in Qt - widgets, QGraphicsView, the web and QtQuick v2. I wonder if they could be harmonized at all? > If you look at the wider picture QML is a replacement for XML based .ui > files, not for any of the other technologies currently used with .ui files. A .ui file gets translated in a fairly straightforward way into an object graph of widgets, actions and other documented classes though. QML adds data binding and other nice features but it also brings a fairly complex runtime with it and that does lead to the interop complications across the C++/JS bridge divide. There were some interesting comments from Tim Sweeney recently about UnrealScript and C++. Some of those comments might equally apply to QML as well: https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4&p=16252&viewfull=1#post16252 On 21 April 2014 14:31, Yves Bailly <yves.bai...@laposte.net> wrote: > On 21/04/2014 04:53, Thiago Macieira wrote: >> Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu: >>> Isn't Qt Widgets so mature that they are stable? >> >> They are. > > But so much could still be done... as a basic example I stumbled upon > very recently, why is it so hard to change the font of *one* item in > a combo box?? > >> The design direction is because QML is easier to develop with, > > Not for heavy-weight applications, even less when part of the UI is > dynamically build at runtime according to context, config files, etc. > >> more modern, >> and based on OpenGL. Widgets don't have that and will never be as efficient. >> Therefore, the effort is directed towards the technology that has the >> potential >> to make interfaces for 2017-2020. > > Even in 2017-2020, we'll still have desktops. Phones or even tablets are just > not suited for *real* work, and I don't see how they could be. A professional > writer can type 100 words per minute on a keyboard, I doubt this will be > even remotely possible on a tablet. Doing serious 3D modeling on a tablet > is a joke. And think about the hundreds of mouse/keyboards shorcuts... if > you remove them, as its the case on "modern" devices, you loose a lot in > productivity. > > QtCreator is a complex application, though not as heavy-weight as some I > work on. Could it be redone "the right way", with *all* the UI in QML and > the "business logic" in C++? would developing QtCreator this way be as > efficient > as it is today? and finally, would a user be as efficient with it on a > "modern" device as he can be on a good'old desktop? Same question for Calligra > and others. > > QML has its merit, it's certainly perfect for some projects. But for all > I've seen and tried until now, only for projects having a rather simple UI. > For really complex UIs, QML seems not suitable - at least for now. > > Mind, what I (and others) is talking about, are applications where user's > productivity matters more than the UI being nice - or even looking "native". > Take Blender: sure, the learning curve is steep. But once you know it, you > can very very productive with it, *on any platform*, because it looks the > same *on all platform*. "Looking native" might be a nice selling or demo > thing, but it's just irrelevant (or even counter-productive) for a whole > class of applications. > > So please, please... keep improving widgets! :-) some things are unnecessary > difficult to do, some features would be so nice to have... > > -- > (o< | Yves Bailly | -o) > //\ | Linux Dijon : http://www.coagul.org | //\ > \_/ | | \_/` > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development