[Development] QtSC: Scene Graph discussion

[Laszlo Papp]

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 <416365416c at gmail.com> wrote:

> On Fri, Aug 2, 2013 at 2:05 AM, Laszlo Papp <lpapp at kde.org> wrote:
> > On 2 August 2013 09:42, Sletta Gunnar <Gunnar.Sletta at digia.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130802/0906976f/attachment.html>