[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