[Development] Question about Qt's future

md at rpzdesign.com md at rpzdesign.com
Mon Apr 21 18:55:17 CEST 2014


Thiago:

I really appreciate your and Intel's participation in the open source Qt
project.

I think you misunderstood what I was talking about and forcefully
rejected that which I did not ask.

I want the "pattern" brought forward, but we should not try to bring the
code forward. Let sleeping dogs lie.

After reading these:

http://qt-project.org/doc/qt-5/topics-graphics.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering

What I think would be a solution is to create a starting point
where Qt Widget 2.0 development could begin anew again based on the
QQuickPaintedItem class.

I think the notion of a Window with child custom controls is not too far
fetched.

My suggestion is basically to provide an early off ramp for QQuickWindow
to allow for 100% C++ projects.

This may even serve as the foundation for custom controls in QML as
well, don't know enough right now to be dangerous.

It would definitely provide current Qt Widget users a sense of ease
that the Widget option is still available even though QtQuickWindow is
the future focus.

QML and QTWidget would then both use the same dual GUI/render thread
foundation, but it would be good to have an early C++ jumping off point
for QQuickWindow based projects.

I do not really care about .ui file support.  For all I can see, 100%
C++ GUI is fine.

What do you think?

Cheers,

md


On 4/21/2014 12:19 PM, Thiago Macieira wrote:
> Em seg 21 abr 2014, às 10:59:43, md at rpzdesign.com escreveu:
>> Can Qt Widgets design pattern be brought forward using the same OpenGL 
>> foundation
>> that QML uses to instantiate controls?
> 
> Short answer: no.
> 
> Long answer: if you want it working in other platforms, without glitches and 
> regressions, the effort required for this is enormous. It basically requires 
> rewriting all or almost all widgets from scratch so that they work in a 
> retained-mode OpenGL scene graph, instead of imperative-mode raster buffer 
> painting. It's a complete paradigm change.
> 
> Since this requires a rewrite, instead of doing it in QtWidgets and risking 
> regressions that users will not accept, the idea was instead to do it in a 
> different module, one where we can experiment and at the same time clean up 
> some of the mistakes that exist in QtWidgets and can't be cleaned up without 
> annoying someone. 
> 
> That's the Qt Quick Components.
> 



More information about the Development mailing list