[Development] The place of QML

[Shawn Rutledge]

On Monday, April 23, 2012 06:59:26 PM ext Alan Alpert wrote:
> On Mon, 23 Apr 2012 17:35:02 ext lars.knoll at nokia.com wrote:
> > On 4/22/12 9:14 AM, "ext d3fault" <d3faultdotxbe at gmail.com> wrote:
> > >...
> > 
> > ...
> > 
> > >To quote Lars,
> > >
> > >We want to make the usage of Javascript supported as well as C++ is
> > >supported. We are not making it the superior way or even the only way.
> > >
> > >
> > >...except that the javascript way currently is the superior way. If you
> > >want a hardware accelerated UI (without hacking together your own...
> > >defeating the purpose of using a UI toolkit), you are forced to use
> > >javascript (QML).
> > 
> > No, you should be using QML. That doesn't imply that you have to write any
> > application logic in Javascript. As I said, use it as a better .ui
> > language. You can still do all your app logic in C++ if you so want.
> 
> I don't think Lars emphasized this enough, but QML is *not* JS. In fact, the
> JS engine is only used when you have non-trivial bindings. The rule of
> thumb is that you have to really write code that looks like JS in order to
> have it interpreted by V8. So if you use it the same way as a .ui file, the
> performance characteristics are almost the same too. For example:
> 
> Rectangle {
> 	x: 10
> 	y: 10
> 	width: 10
> 	height: 10
> }
> 
> This is the level of functionality that UI files provided, and it didn't
> need JS. Well, it still doesn't. That QML code isn't going to run anything
> through V8. The QML engine is smart enough to just assign the values and
> not bother using a JS interpreter. You end up with a C++ object
> instantiated, and with some properties set, which is exactly what .ui files
> did. So if you compare this to a .ui file, the only difference is that it
> is being compiled when you load the component instead of during the compile
> phase. Oh, and it's easy enough to write by hand as well as with the visual
> designer.

Well then it should be possible to write qmlc (like uic), to generate the C++ 
code which will build the UI, so that it's possible to benefit from the 
terseness of the QML syntax but build an app which does not depend on runtime 
parsing or interpreted JS.  I don't think the majority of real-world Qt4 apps 
are loading their UI files at runtime, so it's kindof an unequal comparison; 
the main point of Designer was to avoid having to write tedious GUI code by 
hand, not to eliminate it from existing or to be required to parse UIs at 
runtime.

But can non-constant bindings be evaluated without v8 being involved? e.g. 
width: parent.width - 20 

It's also nice to be able to continue to think of one application as one file 
so that installation is easy.  (Usually there is a user conf file, but the app 
can create that on the first run.)  On MacOS there are app packages; on Linux 
though, if an app is distributed as a binary plus some QML plus a bunch of 
graphics, you can't just stick it in /usr/bin like you can a normal binary 
app.  So the installation is messy.  Every app might need its own directory 
under /opt, or else the app can load the QML etc. from compiled-in resources; 
but if that's to be the preferred way, it should be the default way of 
packaging an app.  Creator and qmake should make it easier to compile-in all 
the resources than not.

BTW GTK has also gone down an unfortunate path, that if you design a UI file 
in Glade you must parse the XML at runtime; there is no longer a code 
generator.  This they say is only because there is no Glade developer who 
wants to maintain such a thing anymore.  So Gnome apps tend to create the same 
sort of mess consisting of at least one or more ui files, a binary, icons, and 
a desktop file, to be installed in "standard" places which are spread across 
the filesystem.  If the future really has to be like that, somebody should at 
least invent a way to have packages like MacOS has, so that there is again a 
possibility of zero-installation.  (And on the flip side, maybe there could be 
pure QML/JS apps which "just run" without needing a customized binary, due to 
being packaged in such a way that the system knows to run qmlscene on the 
"main qml".)

But if QML code was just used to generate parts of the binary, that would be 
both more efficient and simpler, like desktop apps have always been until 
recently; and easier to achieve than getting distros to agree on an OSX-like 
package format.

-- 
MVH, Shawn Rutledge ❖ "ecloud" on IRC