[Development] Question about Qt's future

md at rpzdesign.com md at rpzdesign.com
Mon Apr 21 16:59:43 CEST 2014


Yves & Devs:

I take a different view of tablets.  There MANY use cases where tablets 
will do a HUGE amount of mission critical *REAL* work
and they will NOT use a keyboard or type 100 words a minute.

But I agree, we need both 100% C++ Qt Widget Option (not using .ui 
files) AND QML/js (the new .ui file replacement) for 2017-2020 future.

You can separate the GUI from the Model in C++ Classes as well, not just 
in QML/js vs C++ boundary.

Qt Widgets are currently stable and they work.  (Ignore cosmetic/native 
looking issues- I want program to look SAME across all tablets)

Can Qt Widgets design pattern be brought forward using the same OpenGL 
foundation
that QML uses to instantiate controls?

Peeking at the documentation, QQuickWindow is the container for the 
scenegraph, which has a bunch of
QQuickItems.

Why can't a single QQuickItem == Future Qt Widget?

Any QT Devs expert in the QQuickWindow implementation care to chime in 
on mapping the Qt Widget concept
into the new scenegraph architecture?  (100% C++ GUI, 100% C++ 
Model/Controller)

Obviously, the future QtWidget will have a different pattern than 
current Qt Widget.

Thanks for the lively Monday Qt Future discussion even if Finland and 
Norway are on Holiday!

Cheers,

md


On 4/21/2014 9:31 AM, Yves Bailly 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...
>




More information about the Development mailing list