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.
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.
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.
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.
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.
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.
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]
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.
> You can download a 30-day trial of Qt Enterprise from Digia’s Qt site (version 5.2 is slowly trickling out throughout the day). The open source version can meanwhile be snagged from Qt Project.
Does anybody know the difference between the Enterprise and Open Source versions? Is it just tech support or is the Open Source version going to lack the features we really need?
The license is the critical feature: the open source version is available under GPL and LGPL. Beware of the implications for iOS development with GPL/LGPL (have to distribute source or .o files for your application).
Ok. So if you contribute to the project, you assign copyright of your code to Digia who then dual-license the project to end-users under the GPL/LGPL and for a fee, a commercial license to use it in proprietary applications. Makes sense.
The iOS and Android part is privative. There are open source approaches to do the same, but they don't share code, and use different technology, as far as I remember, the Open source one uses Dalvik while the other not in Android for example.
Does anyone have more info on what the Android/iOS support is like? Does it give native style low level binding ala Mono or does it try to be a generic API that is a write once run everywhere kind of thing?
I'm sure it's even moreso given the different form factors of the various devices. I've given it a decent run and I think it's actually a pretty good system.
I think they would want you to use QML for that. Code your interface in QML, access your platform libraries in Java/Obj-C. This actually makes a lot of sense, since QML can represent just about any GUI logic and you need your native platform libraries anyway.
If you have not tried QML yet: I used to love Qt because it was soo easy, then loved PyQt because it was soo much easier. Now I love QML because it is soo much easier still. QML really is an awesome way of creating GUIs and interaction logic. Then code your backend in whatever language you like. PyQt works just as well as C++, and since you don't have to wrap GUI logic at that point, the language doesn't matter as much.
Actually QML apps can be written only using QML + Javascript. Performance or platform dependent parts can be written in C++.
Some Qt based frameworks experience. Ubuntu Touch chose to develop apps using Javascript only where possible. BlackBerry apps support both Javascript and C++. There are people who believe that QML must be used only for UI and all logic must be written in C++. IMHO Javascript is good choice as it is fast enough in many cases.
As for Python that's not what you want to use with QML and pure Qt is not what you want to use for mobile apps.
Maybe. My experience (not Qt based) with Javascript on iOS is not very bad (I expected worse). While I don't like that Apple created fake problems using script languages in iOS.
Regardless of qt, you can actually already write android and iOS apps in python via kivy (http://kivy.org/#home).
It includes a domain specific language for creating widget trees called kivy language, which I hear is not unlike qml (though I haven't tried the latter), though it all maps straight to pure python if you want to write things that way.
I have no idea about iOS, but I have tried porting some QWidget based apps on Android using 5.1 (not tried 5.2 yet), and they did work but poorly. Some widgets looked downright ugly and some had layout issues.
I ended up rewriting my UI in QML instead and that worked very well.
From the article:
Update at 11:00 AM EST: Digia has contacted TNW [TheNextWeb] to say that “some last minute technical issues” have delayed the launch until December 12. Downloads are now expected to go live at 10:00 AM CET (4:00 AM EST) [9:00 GMT], or about 22 hours later than previously planned.
Lets hope that tools and frameworks like this will be widely adopted, thus more and more jobs requiring these skills, rather than that crap, over-engineered "native" SDKs/frameworks...
The modern Android and iOS SDKs are both really quite nice. There are obviously weak spots in both, but neither could really be described as "crap" or "over-engineered." I'm not familiar with WinRT.
Still, Qt is pretty impressive. The main problems it suffers from are it's weight, and the issue that all cross-platform frameworks suffer from, in that the GUIs never feel quite right.
What's over engineered about Android? I work with it daily and find it quite nice and it really didn't take too much effort to dive into.
Also if you want something small and simple, I think QT might be the wrong tree to bark up. I've only used it on casually used it on desktop but it is not a small framework.
Agreed. Qt is not as small and simple as it used to be. If you're a dinosaur like me still using it on smaller platforms, the QtCore and QtGUI libraries can run you north of 10MiB of space. And now QtNetwork always wants to link in, and I can't get it to detach from the link like the old 4.x days.
"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.