5 ms·

Anyone have a good link (video? blog entry?) discussing what problem QML solves and why it is better than other solutions? Within the docs the biggest thing I

by icefox 13y ago

Anyone have a good link (video? blog entry?) discussing what problem QML solves and why it is better than other solutions? Within the docs the biggest thing I am able to find is the following hand wavy statement: "QML is a user interface specification and programming language. It allows developers and designers alike to create highly performant, fluidly animated and visually appealing applications. QML offers a highly readable, declarative, JSON-like syntax with support for imperative JavaScript expressions combined with dynamic property bindings." I have heard about it for a number of years, but never been able to wrap my head around everything it is offering and why various choices were made.

blub 13y ago
The problem it tries to solve is preventing UIs from being defined in C++ (or Python, etc) when the Designer doesn't cut it any more. Sure, QML is still a type of code, but it's much cleaner and easier to read & write.
deleted 13y ago
[deleted]
daliusd 13y ago
Since I have some experience with QML (Symbian, Meego, Ubuntu Touch and BlackBerry 10) I will try to answer this question as simple as possible: There is wet developer dream to write software that can be written once and used everywhere. In mobile area one way to accomplish this dream is to use HTML + CSS + JS. HTML while being good for web pages is not the best choice for apps (while it gets better). Now you can replace HTML with QML. It is better than HTML because you declare everything in UI paradigms like rectangles, text, gradients and etc. (QML can be styled using CSS as well while that's not very necessary). Unfortunately I have not managed to persuade people above me that we should try out QML and HTML is their choice (e.g. because of Win8 support). Does QML solves run everywhere problem? Most probably no, each platform expects some "native" feel (even if "native" is done in QML). E.g. Blackberry and Ubuntu users expects sliding menus, Android users expect working back button and etc. Native always win over cross-platform if you want to win users while I would love to see cross-platform solutions working.
sho_hn 13y ago
I can think of a number of different approaches to try and explain it, loosely building on each other: 1) If you've used Qt before, you can think of QML files as next-gen .ui files. Like .ui files, QML files allow you to instanciate objects implemented in C++, set properties on them and declare connections between them. However, unlike .ui files they can also instanciate things implemented in QML, and they can evaluate JavaScript expressions. 2) The latter is quite powerful. Expressions can be bound to properties (example: c: a + b), and if properties referenced in an expression (i.e. a and b in the example) change, it will be re-evaluated and thus the value of c will change. This is a simple principle that tends to eliminate an entire class of UI bugs by dropping an entire class of scaffolding code, namely code written to update values somewhere in response to changing state in the system. This is the declarative style - the correct state sort of arises out of the description of the system the files hold, instead of needing to write procedural, step-by-step code to get it there. 3) On top of ideas like this, QML has an excellent anchor-based layouting system and well thought-out ways to inject things like animation behavior into property and state changes. It's also implemented on top of a modern OpenGL scenegraph that does sophisticated draw call batching, texture atlasing and so on, so its performance is game-like. It's also easy to get your own stuff in there. Combined with what Qt offers in terms of writing serious C++ backends to UIs written in QML, I'm a fan.
pessimizer 13y ago
It's just a cross-platform UI markup language, as far as I know. It solves the problem of creating a cross-platform UI, and whether it is better than other solutions is a matter of preference. https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML
nsm 13y ago
For one thing it has a much better box model than CSS/HTML, layouts are much nicer. It allows you to have a scripted UI in C++ apps, but there is no reason someone couldn't write a codegen to spit out HTML/CSS. There is already one called qmlweb but not sure if its maintained. It also has bits of reactive programming so that value changes in variables propagate to uses of that variable, making it really easy to have fluid layouts, or to recalculate labels or similar. I like to think of it as a better presentation layer than HTML/CSS. I made a game 2 years ago using QML + JS [1] [1] https://github.com/nikhilm/solarwolf-qml https://github.com/nikhilm/solarwolf-qml
Timmmmbob 13y ago
I've used QML / QtQuick for a while. Here are my thoughts 1. It makes writing UI state machines much simpler since it is declarative. Instead of saying "when this information changes, update the UI", you just say "This bit of UI shows this information" and then it updates it does it automatically. 2. Animation is also much easier (and possible at all). 3. Layout is... myeh it is not so good actually. UI files made it really really simple, but QML has a kind of Android-like overcomplication to it. For example I have no idea how to have two buttons above each other with the same width and have that width the minimum required to fit them both. With the old system I didn't even have to think about that. 4. Javascript was a seriously bad choice. Fortunately you don't write that much of it (and the non-javascript parts of QML are well designed). The biggest problem is that you have to run code to have even the vaguest idea that it will work (probably you misspelt a variable). With C++ if it compiles you at least have some idea that it will work. Also there is a lot of hassle converting between C++ values and javascript objects. Particularly for lists/vectors of things which work very badly and... to be honest does not really work. 5. It does force you to separate your logic and UI - kind of like HTML/CSS. This is a good thing generally. 6. Once you've done the hard C++ work, building the UI is much quicker and less verbose than using the old system. It is also easier to change around. In generally they are going in the right direction. They just made a huge mistake by choosing javascript. They've ended up writing their own javascript VM too, so I don't know why they didn't take the opportunity to use a sane, strongly typed language.
- thomaszander 13y ago
  The history of the VMs is that many years before there was QML there was QtScript. A Javascript based engine. This got used for Qt4. In Qt5 the V8 open source engine got used instead. Either way, they ended up picking something that was already there, which would explain why it was easier than creating a brand new langauge.
- alok-g 13y ago
  Is using Javascript mandatory (for common uses)?
  - daliusd 13y ago
thomaszander 13y ago
QML was the natural extension of where Qt was evolving to. With listviews in itemviews-ng having delegates that were just a set of graphics-view objects, QML took it one step further by defining it in QML. The effect is really an amazingly well working separation of concerns. The biggest and simplest reason is that when you can wrap your head around QML, it takes no time at all to write a good UI. So, the goal changes from having a complicated UI that has to work well on 5 different form-factors to instead have up to 5 different UI layers to work best on those form-factors. You really can write a good looking UI in a fraction of the time compared to a QWidget approach. Most of QML is based on core Qt/QObject concepts. A binding is just a combination of a signal, getter and maybe setter. Just to state again that this is just a extension of the direction Qt had been going in for some time already. See for a simple overview; http://www.youtube.com/watch?v=_6_F6Kpjd-Q http://www.youtube.com/watch?v=_6_F6Kpjd-Q ps. I didn't "get" it until I took part in a kdab course. Its really not that trivial to wrap your head around ;)

by icefox 13y ago

blub 13y ago

The problem it tries to solve is preventing UIs from being defined in C++ (or Python, etc) when the Designer doesn't cut it any more. Sure, QML is still a type of code, but it's much cleaner and easier to read & write.

deleted 13y ago

[deleted]

daliusd 13y ago

Since I have some experience with QML (Symbian, Meego, Ubuntu Touch and BlackBerry 10) I will try to answer this question as simple as possible: There is wet developer dream to write software that can be written once and used everywhere. In mobile area one way to accomplish this dream is to use HTML + CSS + JS. HTML while being good for web pages is not the best choice for apps (while it gets better). Now you can replace HTML with QML. It is better than HTML because you declare everything in UI paradigms like rectangles, text, gradients and etc. (QML can be styled using CSS as well while that's not very necessary). Unfortunately I have not managed to persuade people above me that we should try out QML and HTML is their choice (e.g. because of Win8 support). Does QML solves run everywhere problem? Most probably no, each platform expects some "native" feel (even if "native" is done in QML). E.g. Blackberry and Ubuntu users expects sliding menus, Android users expect working back button and etc. Native always win over cross-platform if you want to win users while I would love to see cross-platform solutions working.

sho_hn 13y ago

I can think of a number of different approaches to try and explain it, loosely building on each other: 1) If you've used Qt before, you can think of QML files as next-gen .ui files. Like .ui files, QML files allow you to instanciate objects implemented in C++, set properties on them and declare connections between them. However, unlike .ui files they can also instanciate things implemented in QML, and they can evaluate JavaScript expressions. 2) The latter is quite powerful. Expressions can be bound to properties (example: c: a + b), and if properties referenced in an expression (i.e. a and b in the example) change, it will be re-evaluated and thus the value of c will change. This is a simple principle that tends to eliminate an entire class of UI bugs by dropping an entire class of scaffolding code, namely code written to update values somewhere in response to changing state in the system. This is the declarative style - the correct state sort of arises out of the description of the system the files hold, instead of needing to write procedural, step-by-step code to get it there. 3) On top of ideas like this, QML has an excellent anchor-based layouting system and well thought-out ways to inject things like animation behavior into property and state changes. It's also implemented on top of a modern OpenGL scenegraph that does sophisticated draw call batching, texture atlasing and so on, so its performance is game-like. It's also easy to get your own stuff in there. Combined with what Qt offers in terms of writing serious C++ backends to UIs written in QML, I'm a fan.

pessimizer 13y ago

It's just a cross-platform UI markup language, as far as I know. It solves the problem of creating a cross-platform UI, and whether it is better than other solutions is a matter of preference. https://en.wikipedia.org/wiki/QML https://en.wikipedia.org/wiki/QML

nsm 13y ago

For one thing it has a much better box model than CSS/HTML, layouts are much nicer. It allows you to have a scripted UI in C++ apps, but there is no reason someone couldn't write a codegen to spit out HTML/CSS. There is already one called qmlweb but not sure if its maintained. It also has bits of reactive programming so that value changes in variables propagate to uses of that variable, making it really easy to have fluid layouts, or to recalculate labels or similar. I like to think of it as a better presentation layer than HTML/CSS. I made a game 2 years ago using QML + JS [1] [1] https://github.com/nikhilm/solarwolf-qml https://github.com/nikhilm/solarwolf-qml

Timmmmbob 13y ago

I've used QML / QtQuick for a while. Here are my thoughts 1. It makes writing UI state machines much simpler since it is declarative. Instead of saying "when this information changes, update the UI", you just say "This bit of UI shows this information" and then it updates it does it automatically. 2. Animation is also much easier (and possible at all). 3. Layout is... myeh it is not so good actually. UI files made it really really simple, but QML has a kind of Android-like overcomplication to it. For example I have no idea how to have two buttons above each other with the same width and have that width the minimum required to fit them both. With the old system I didn't even have to think about that. 4. Javascript was a seriously bad choice. Fortunately you don't write that much of it (and the non-javascript parts of QML are well designed). The biggest problem is that you have to run code to have even the vaguest idea that it will work (probably you misspelt a variable). With C++ if it compiles you at least have some idea that it will work. Also there is a lot of hassle converting between C++ values and javascript objects. Particularly for lists/vectors of things which work very badly and... to be honest does not really work. 5. It does force you to separate your logic and UI - kind of like HTML/CSS. This is a good thing generally. 6. Once you've done the hard C++ work, building the UI is much quicker and less verbose than using the old system. It is also easier to change around. In generally they are going in the right direction. They just made a huge mistake by choosing javascript. They've ended up writing their own javascript VM too, so I don't know why they didn't take the opportunity to use a sane, strongly typed language.

thomaszander 13y ago
The history of the VMs is that many years before there was QML there was QtScript. A Javascript based engine. This got used for Qt4. In Qt5 the V8 open source engine got used instead. Either way, they ended up picking something that was already there, which would explain why it was easier than creating a brand new langauge.
alok-g 13y ago
Is using Javascript mandatory (for common uses)?
- daliusd 13y ago

thomaszander 13y ago

QML was the natural extension of where Qt was evolving to. With listviews in itemviews-ng having delegates that were just a set of graphics-view objects, QML took it one step further by defining it in QML. The effect is really an amazingly well working separation of concerns. The biggest and simplest reason is that when you can wrap your head around QML, it takes no time at all to write a good UI. So, the goal changes from having a complicated UI that has to work well on 5 different form-factors to instead have up to 5 different UI layers to work best on those form-factors. You really can write a good looking UI in a fraction of the time compared to a QWidget approach. Most of QML is based on core Qt/QObject concepts. A binding is just a combination of a signal, getter and maybe setter. Just to state again that this is just a extension of the direction Qt had been going in for some time already. See for a simple overview; http://www.youtube.com/watch?v=_6_F6Kpjd-Q http://www.youtube.com/watch?v=_6_F6Kpjd-Q ps. I didn't "get" it until I took part in a kdab course. Its really not that trivial to wrap your head around ;)