What?

Hi, Habr! Many years have passed since I wrote here. I hope the time of you / me is not too / too patched.

I would like to write about our experience rethinking QML ideas. Qt is an excellent (by virtue of merit) library, and although its internal structure sometimes raises questions , it has given the world not only a cross-platform UI toolkit, but also a solid professional set of tools: Designer, Creator, Linguist, and, of course, Qml . The result of this rethinking was our modest project that turns qml into html5 / javascript for different platforms, and even allows you to build simple android applications using Cordova .

Qml has always attracted us (a small unknown group of QML lawyers, as we call ourselves, putting on monocles and cylinders) with its absolute expressiveness in terms of developing interfaces, and therefore each of us uses them to develop user interfaces and sites.
')
We would very much like a part of the Habr community, open to everything new, to try and appreciate our modest possibilities, we received feedback, and could improve our product.

Source codes are available on github , the source codes of the site, examples and the library of controls that we use for all our projects are also there. Documentation and lessons can be viewed on our website, pureqml.com .
If you do not understand something, you can join the Telegram support group , we will try to answer all the questions in real time.

One of the free apps that we made was the port of the Fontanero game, it should be available in the LG / Samsung markets.

Well, then you can not read!

How we came to such a life

It all started back in 2010, when we started writing embedded software (and user interface) in one large corporation for a line of disparate devices on various platforms that are available now: arm, mips, x86, sh4, all that was missing was sparc ...

We formulated the main problem for ourselves: UI should be fast, cheap and good, and so that it is not necessary to choose only two points from these three. There were very few resources (one and a half programmers), so I wanted the UI programming to be easy and pleasant, and the programmers did not suffer, did not cry, and did not run away, but focused on solving business problems, instead of manually tracking coordinates. HTML was dropped immediately, partly because the very first device was on arm926xxx (armv5) and had 32 MB of RAM onboard, of which only 23 MB was available for user-space applications (and also armv5 has a funny limit of 2G virtual addresses for all processes in the amount, correct me if I am mistaken), which greatly narrows the scope for searches.

After analyzing the existing solutions, our choice fell on a relatively new (then) language and technology - QML, which was not at all surprising given the previous positive development experience with Qt. Exceptionally simple and visual, we immediately decided that this was what we needed. A very functional prototype, which appeared in a week, sparkling from fashionable animations, even more convinced us of the correctness of the choice.

QML - (Enough) Fine

The most beautiful thing about QML is that it hides everything from the programmer, except for the UI itself. You just have to take the idea in hand, and splash out on the canvas!

The declarative approach is very intuitive and easy to use. The reuse component is intuitive, and, for simple cases, very concise. This allowed us to make a full-fledged UI (menus, applications, settings, schedules, and other things), in just a couple of months, by two programmers.

We spent a lot of time on trapping Qt, but it turned out that even custom builds, without a drop of excess, do not fit in either 8 or 16 MB of flash memory. Our sadness knew no bounds, because we already lived in a world where embedded interfaces were no longer dull and were indignant, recalling the times when there was no Qt QML.

That evening, my colleague and I spent the evening drinking a bottle of Qingdao in one of the Shenzhen hotels (on the 48th floor!), Wondering whether it was possible to make QML, but in C ++, and at the same time, check the strength of that sad platform on arm926. It turned out that everything is not so bad, and the processor has enough capabilities to draw transparent beautiful windows even software, and there was also a 2d graphics accelerator!

Having rolled up our sleeves and discarded Qingdao, we began to compile violently, and after a couple of weeks we already had our QML with C ++ instead of javascript. This was our first QML of our own, which we polished for a long time, to the bitter end.

But C ++ is quite hardcore, and it imposes its limitations, for example, you cannot distribute applications for different platforms, native code compiles for a very long time, is more demanding on the brain of a programmer, and requires more investments. Therefore, in a couple of years, when we with the (other) colleague whiled away the evening at the pies in one of the Amsterdam coffee shops, we figured out how to return the javascript (represented by v8) to the native code.

This background story may not be very interesting, because those two QML are in the past, along with the very corporation where they were born. They never appeared before the general public as a development tool, but the UI built on this technology uses about six million people on a daily basis.

Our days (a year and a half ago)

After leaving this large and scary corporation, we also wanted to quickly and easily develop interfaces, and at the same time there was a need to write a large and complex application for SmartTV, immediately on 5 (!) Platforms. Android for TVs had not yet come out, and all SmartTV then (like most now) offered an HTML-based SDK, promoting its frameworks and libs to make life easier for programmers (for example, caph from samsung), but this rather complicates the process, since the implementation One UI needed to be rewritten under the framework of each specific manufacturer. The motivation of their (manufacturers) TVs to use web-based technologies is understandable, but the implementation becomes very painful as the complexity of the application increases. Having a five-year experience of writing our own QML engines, we decided to make another own QML (we need more bikes!) , But for SmartTV in particular, and for HTML in general.

So our modest project was born.

Basic instinct principle

Everything is arranged almost as in qml, all components are described in .qml files, in .manifest the structure of the application is described. Next comes the translator / transpiler (?) QML in html5 / javascript: signals, updates, prototypes and constructors are generated and connected. After the translation, a compact and fast javascript file is obtained, along with an html-launcher, requiring only Modernizr .

A distinctive feature is that we wrote QML in QML, all core components are written in qml and javascript, using our toolchain, the transpiler itself only decomposes files into namespaces and generates what they usually write with their hands.

Translation difficulties and bicycles

The QML dialect we use is very similar to the original QML. The most important change is that we redid the logic of the focus, making it simpler and safer.

In general, we try to maintain compatibility with Qt QML and sometimes arrange cross-hikes on discrepancies.

Since we use HTML5 as the main platform (probably, it’s not very fashionable to say this, I don’t know for sure) , we use HTML as a simple drawing system for 2d graphics, positioning the elements (div) absolutely, relative to the parent. This allowed us to fully implement the impurities, for example, to allow any element to handle hover or click events without using the terrible MouseArea monster. You can also add a Border, Gradient or Drag-n-Drop to arbitrary elements without creating an additional element, and without creating a bundle Item-MouseArea.

Current state

Obviously, with a small organized programmer group of three people, we did not implement all the components and functions included in Qt QML, but a significant part, the most useful, in our opinion, we did.

A documentation generator and a navigator on it, like the skeleton of the documentation itself, are created using doxygen-like annotations. Required to clean up the library components.
Finalize instructions and tools for Windows and MacOS.

We have a lot of ideas for optimization, functional enhancement and platform improvements, and more.

Nevertheless, the core of the project is already quite stable, and we, by this time, managed to release several commercial projects (and several non-commercial) on our PureQML.

We are looking forward to your feedback, and if someone wants to do something really working, it will be just fine!

To all who read this confession to the end, thank you so much!

If this article is interesting to anyone, we can continue to consider our QML vision, the development of impurities, integration with different platforms at different levels, declaratively and not, improving the language, adding dimensions to the declaration (%, em, pt).

We have so far decided not to open source codes for smartTV platforms, but, in general, we are considering this possibility. If you want to get a version for SmartTV, write in the comments, we will think in what form it can be done.