[Development] Question about Qt's future

Robert Knight robertknight at gmail.com
Mon Apr 21 16:13:08 CEST 2014


> 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.bailly at laposte.net> wrote:
> On 21/04/2014 04:53, Thiago Macieira wrote:
>> Em dom 20 abr 2014, às 22:37:11, md at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list