Hmm, I have not mentioned "good old rendering engine". If I wanted to do that, probably this scene graph thread would be inadequate. ;-)
To me, your post reads like if a hardware accelerated ui building technology like this was inherently tight to QtQuick and QML. If that is the case, and Qt has no plans for fixing that, I would not be surprised if opengl empowered ui c++ frameworks would gain more popularity again, such as fltk on embedded, for instance, even though it has certain limitations. On 2 August 2013 19:12, Alan Alpert <[email protected]> wrote: > On Fri, Aug 2, 2013 at 2:05 AM, Laszlo Papp <[email protected]> wrote: > > On 2 August 2013 09:42, Sletta Gunnar <[email protected]> wrote: > >> > >> > >> > The audience may not need it, but I would. :-) "less pressing" means > it > >> > is not high priority for you, but contribution is welcome? > >> > >> 1 makes it possible for anyone to do 2-4 outside of Qt, and unless there > >> are convincing arguments why they should be there in Qt, I don't think > they > >> should be there. > > > > > > I really hope this is not equivalent to that only QtQuick/QML is meant > to be > > supported in the Qt Project. We still have QtWidgets maintained inside > the > > Qt Project for good. I really hope the good old way of developing > > applications with C++ without the QML interpretation and higher layers > will > > still be available. > > The good old way is still provided with the good old widgets using the > good old rendering pipeline. As you said that's still being maintained > in a separate module, it doesn't strictly need to share any rendering > infrastructure with other UI approaches even inside Qt. > > QtWidgets and QtQuick are both excellent and specialized tools for > building different styles of UI. Nothing's changing for good old UIs, > but you can't expect a completely new framework for a completely > different use case to behave in the exact same 'good old way'. That > just makes it harder for the target audience to use it in the > 'value-pending new way' because of the overhead of supporting extra > use cases. > > -- > Alan Alpert >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
