[grey-area]

When I last read about Ubuntu Phone, they were offering two choices for UI, QML, and HTML widgets, but perhaps QML is their preferred option? If so that's a shame but not a huge issue for me. All these XML markup languages for views (xib, XAML, QML) offer very little over html IMHO and end up tying you in to one set of tools provided by the vendor. I'd rather they just focussed on improving the OpenGL backed performance of webkit animations to bring it up to scratch instead.

[sho_hn]

QML isn't XML-based. It's synxtax is compatible with ECMAScript and it allows embedding ECMAScript expressions and code (but it's style is generally declarative with procedural code discouraged).

And it has a lot to offer over HTML. It has a better layout model for one, sane integration of concepts like animated property transitions and behaviors, makes it far easier to put custom objects backed by native code into the scene, and many other advantages. A lot of these things aren't possible declaratively in HTML, and HTML isn't set up to be extensible enough as a language so you could make up for it yourself. Yes, you can jam everything into a HTML document somehow, but that doesn't mean it's always a pleasant way to go, or that HTML is the peak of UI technology.

[grey-area]

QML isn't XML-based.

Thanks for the correction, I was thinking of xib, XAML, Activities etc. haven't used QML, though I have used Qt, a while ago now. One thing I do think HTML got right is to separate content and code, so putting my UI markup into a js-like format which potentially mixes in code is even less appealing :)

Yes, you can jam everything into a HTML document somehow, but that doesn't mean it's always a pleasant way to go, or that HTML is the peak of UI technology.

While there's a lot wrong with HTML, and I agree there's much to be improved in its layout model, learning and keeping in our head a new layout model just to place some buttons and UI controls on a page every time we switch platforms is painful, and leads to fragmentation and lock-in where people choose a platform and stick with it, because they've had to invest so much time learning those platform specific tools. I think that's a shame and it's not a pain I look forward to when moving platforms. Depends on your focus I suppose - if you plan on using one platform exclusively or using Qt everywhere, it won't bother you.

From my perspective doing work for clients on content-heavy apps, often with web integration, there's an awful lot of content already in html, it provides good control over text styling (typically far better than native equivalents), and it means content is portable between the web and apps, so for those pragmatic reasons I find HTML more appealing for presenting content, even for many UI controls.

For example if I have an Android app, an iOS app, and an Ubuntu Phone app, I have 3 different platforms to manage, each with their idiosyncrasies, differing features, layout language, and blessed platform language, and then I have a load of content which I have to let users generate, manage and get into apps on each platform, using web tools to do so is significantly less painful.

It's not a huge deal as you can obviously use webviews and frame html content with native controls for each platform, but I wish Ubuntu had taken a step towards the web instead with the phones rather than focussing on desktop technologies. I see why they'd want to tie it in with what they're doing on the desktop though. Sorry for the thread hijack!

[zanny]

Qt just released 5.1, which has prelimiary ios and Android support. By the end of the year, you will be able to write a Qt application, and use a QML ui. You can even use one single UI across all devices, where the UI dynamically adds or substracts elements depending on screen size. IE, responsive design for applications.

It is pretty close to write once, run anywhere. The only downside is if your app is the first qt app installed on an ios / android device, it forces a download of the shared libraries which are quite large. You also have to build the applications against individual platforms, since you are using C++, and the finished binary is a native application that uses the qt libraries to launch the qml engine and v8 for the javascript parts.

One experiment I am anxious to see come to fruition in the qt space is the KDE project to get qml apps running in the browser : https://projects.kde.org/projects/playground/www/qmlweb. Since QML is inherently javascript, a web app could only use javascript / qml to create a restrcited sandbox (or nacl / other browser equivalent for the c++ parts) and the entirety of qtquick is designed around high latency elements, so it can support network transport.

[grey-area]

On iOS at least dynamic libraries are not allowed outside those Apple provides, so I'm not sure how that would work. I imagine they'll have to compile in the Qt runtime on iOS at least. I'll be interested to see their efforts in this space, but Qt everywhere is not particularly attractive to me, nor is working in C++ or javascript with qml.

I do wish these platforms were a little more agnostic to the technology used in their API, and had simple C bindings anyone could write glue code for to use their favourite language. Learning yet another markup language and using C++ in order to create apps doesn't really appeal. Whatever the platform insists on as glue is what we'll have to use though, as usual. Personally I'm going to look into the webapp support in Ubuntu Phone to see if it supports local web apps, and hope that I can use that glue to get at any device state that I need to access.

As to qml in the browser, I'd really rather have web apps on the desktop than start writing websites in qml, I'd be very surprised if that catches on.

[lukifer]

> The only downside is if your app is the first qt app installed on an ios / android device, it forces a download of the shared libraries which are quite large.

How does this get around sandboxing on iOS? My fuzzy understanding is that components would need to be downloaded for each app independently. And is there a reason those shared libraries can't be bundled?

[zanny]

No idea, never tried it. A cursory browsing of qt documentation suggests it can't, and it also can't use qtquick2, which is where qml becomes really useful (which is also when it starts using v8).

[sho_hn]

That's incorrect. QML has used v8 since its initial appearance in Qt4. In fact, it will move away from v8 in Qt 5.2 is the current plan.

[sspiff]

I recently made a toy project with QML. It was my first Qt experience and I think I'll be using QML for just about any GUI I want to create in the future, it's a really clean and nice way of working.

[mateuszf]

Well, using Angular.js in a good way would actualy make possible to have the same flexibility without adding any code to the view layer.

That said, it is possible but still not that easy to do. Native solution will probably be faster, more energy efficient and easier to use.