Qt 5.0 Beta Not Here Due To Difficulties

[TheBlackCat]

EFL disagrees with you. Scene graph in C.

As I said, you can embed a declarative language in C++ (which, as far as I can tell, is exactly what EFL does), but it won't be qwidget-based.

[jrch2k8]

Because that is the whole point of using a declarative language. With an imperative language like C++, you have to tell the system exactly how to do what you want it to do. With a declarative language you tell the system what you want in the end, and the system figures out the best way to accomplish it. And the latter case is exactly what scenegraph is all about, it knows what the finished product should look like, so it can then figure out exactly how to go about producing that in the most efficient possible way. That is fundamentally impossible with an imperative language like C++, where you have to manually lay out each rendering step.

I guess, theoretically, you could embed a new declarative language inside C++ code, but that really doesn't do what you want it to do, because it still wouldn't be C++, in the end it would still be a new language.

And you can't do it at all with qwidget, since by definition qwidgets have their rendering code inside the class, which is exactly what scenegraph was designed to avoid. So no matter how you implemented the declarative language, you could never use qwidget.

mmm scenegraph is a render engine concept not a QML foundation and as far trolls[as trolltech] has explained there is a previous stage before scenegraph that convert the QML Js code to C++ hence the render is done in C++ internally, the problem here [RealNC is right in this one] that for some reason they are not providing yet[i hope] a way to access scenegraph directly from C++ which is needed for proffesional applications[QML is more for mobile and pops grocery app] cuz QML can't handle real complex stuff keeping decent speeds and the logic interfacing with C++ is not smooth in complex code.

so the ideal scenario is that QWidget\others can render using scenegraph as engine because as far c++ devs care this is the only "but" and well maybe a smarter way to expose Webkit API so Qt is not always behind

beside i maintain my position QWidgets are way more powerful than QML in anything except eye candy[in the sense that is a bit harder to code] at least for the experienced developers

[TheBlackCat]

mmm scenegraph is a render engine concept not a QML foundation and as far trolls[as trolltech] has explained there is a previous stage before scenegraph that convert the QML Js code to C++ hence the render is done in C++ internally,

Do you have a source for this? As far as I can tell, QDeclarativeEngine is the interpreter for QML, it is written in C++, but QML is converted into bytecode that the interpreter analyzes and makes use of. In a sense it is similar to how the python interpreter is written in C, but that doesn't mean python code is converted to C code (nor is it always even possible to do so).

the problem here [RealNC is right in this one] that for some reason they are not providing yet[i hope] a way to access scenegraph directly from C++ which is needed for proffesional applications[QML is more for mobile and pops grocery app] cuz QML can't handle real complex stuff keeping decent speeds and the logic interfacing with C++ is not smooth in complex code.

Scenegraph is, you know, a scene graph. The whole point is that you only provide the scene graph, and the interpreter decides how to make use of it at runtime. Using C++ to control how the scene is handled completely defeats the purpose of using a scenegraph in the first place. By definition you need to hand control of the UI over to the scenegraph interpreter or you completely lose the benefit of using a scenegraph in the first place.

so the ideal scenario is that QWidget\others can render using scenegraph as engine because as far c++ devs care this is the only "but"

As I keep explaining, QWidget is based on a completely different underlying structure. In QWidget, the widgets handle their own rendering. In scenegraph, all the rendering is handled by the interpreter. You fundamentally cannot render QWidget using a scenegraph without pretty much completely rewriting it from the ground up, at which point it would be just like QML in the end anyway.

beside i maintain my position QWidgets are way more powerful than QML in anything except eye candy[in the sense that is a bit harder to code] at least for the experienced developers

Yes, again, that is because with QWidget the developer writing the widget controls the rendering, and thus can have very fine-grained control of how it operates. But by doing that, you can no longer use scenegraph, because the whole point of scenegraph is that it controls the rendering, not the developer.

You can't have it both ways. Either you control the rendering, or scenegraph does. You want the benefits of scenegraph, but without the changes in the painting system that make scenegraph possible in the first place.

[jrch2k8]

Do you have a source for this? As far as I can tell, QDeclarativeEngine is the interpreter for QML, it is written in C++, but QML is converted into bytecode that the interpreter analyzes and makes use of. In a sense it is similar to how the python interpreter is written in C, but that doesn't mean python code is converted to C code (nor is it always even possible to do so).


Scenegraph is, you know, a scene graph. The whole point is that you only provide the scene graph, and the interpreter decides how to make use of it at runtime. Using C++ to control how the scene is handled completely defeats the purpose of using a scenegraph in the first place. By definition you need to hand control of the UI over to the scenegraph interpreter or you completely lose the benefit of using a scenegraph in the first place.


As I keep explaining, QWidget is based on a completely different underlying structure. In QWidget, the widgets handle their own rendering. In scenegraph, all the rendering is handled by the interpreter. You fundamentally cannot render QWidget using a scenegraph without pretty much completely rewriting it from the ground up, at which point it would be just like QML in the end anyway.


Yes, again, that is because with QWidget the developer writing the widget controls the rendering, and thus can have very fine-grained control of how it operates. But by doing that, you can no longer use scenegraph, because the whole point of scenegraph is that it controls the rendering, not the developer.

You can't have it both ways. Either you control the rendering, or scenegraph does. You want the benefits of scenegraph, but without the changes in the painting system that make scenegraph possible in the first place.

1.) Qt beta blog at qt.nokia.com look for the commentary section in the many scenegraph articles since the official devs explain this a bit more based on question
2.) let me express a bit more precisely here QSceneGraph seem to have 2 uses or components
a.) is a scene interpreter needed for QML to render in here i agree with you totally named QDeclarativeEngine and here C++ devs have no complains or interest at all
b.) the rendering engine which is more tied to lighthouse project than QML that provide many nice advances in the render/texture management/shaders/object relation in the framebuffer/canvas operations in hot at the GPU,text|glyph rendering between others <--- this is the part we want to be exposed to the C++ API[seem they wanna to stabilize some more before allow this] and be as flexible as QtPainter/QGLpainter so we can reimplement selected render operation to adapt it to more complex projects and allow at the same time to speed QWidgets render.

The problem is QML is nice for the mobile space[<-- nokia ...] and graphic simple applications that need cool eye candy but for lets say a multi layered massively tiled rendering[GIS/CAD/etc] or lets say multi input HD video RT processing is deadly slow. i know this is better done in c++ side but you have to rewrite half QT render path to achieve it and many of this changes are already in this engine and using it properly will save you from a truckload of code and hacks, so if they make this changes later in another revision everyone with this kind of workload can make good use of this technology without reinvent the wheel everytime <-- that is all the issue here