Qt 5.0 Beta Not Here Due To Difficulties

[RealNC]

Declaritve programming is very good for for UIs though

I strongly disagree.

[ShadowBane]

I strongly disagree.

Ok, so if declaritive programming is worse for UIs than imparitive programming why is the use of declaritive languages to create user interfaces on the rise?

Also, what exactly makes imparitive languages good for user interfaces?

[RealNC]

IMO GUI programming is nothing special. It doesn't need special treatment from a programmer's point of view. The need for non-programmers to create GUIs is the reason for this move. GUI designers who know Photoshop but not C (or similar languages), can now create GUIs (you can export QML from graphics tools.)

That's good. I support it. But don't shut me off from being able to work with my preferred tools for no reason. QML is not better for me. It's better for others, because they can't use what I use.

[TheBlackCat]

IMO GUI programming is nothing special. It doesn't need special treatment from a programmer's point of view. The need for non-programmers to create GUIs is the reason for this move. GUI designers who know Photoshop but not C (or similar languages), can now create GUIs (you can export QML from graphics tools.)

It isn't quite that simple. QML allows for the new scenegraph system, which apparently improves GUI performance considerably and allows for smooth animations like transitions. So there are specific technical benefits to it besides making it easier for non-programmers.

That's good. I support it. But don't shut me off from being able to work with my preferred tools for no reason. QML is not better for me. It's better for others, because they can't use what I use.

Nobody is shut off from anything, qwidget is still there in Qt 5.

[RealNC]

It isn't quite that simple. QML allows for the new scenegraph system, which apparently improves GUI performance considerably and allows for smooth animations like transitions. So there are specific technical benefits to it besides making it easier for non-programmers.

That's not QML. That's the underlying base code. You get access to it through QML only.

It seems you missed the point (even though I wrote it down many times). So I'll write it once again: Why *only* QML?

Nobody is shut off from anything, qwidget is still there in Qt 5.

"Improves GUI performance considerably and allows for smooth animations like transitions."

You're shut off from that with QWidget.

[TheBlackCat]

It seems you missed the point (even though I wrote it down many times). So I'll write it once again: Why *only* QML?

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.

[curaga]

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.

EFL disagrees with you. Scene graph in C.

[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.