Marcin Juszkiewicz - qt

QML - Quality Matters Last?

2018-10-14T14:01:00+02:00

In 2004 I was newbie in embedded Linux area. Decision to buy Sharp Zaurus instead of HP iPaq got me to Qt/e world rather to GTK one. I was also KDE user rather than GNOME2 as well so I can say that I liked Qt already.

All those sizes in pixels, paddings and margins I saw in GTK code made me feel sick each time I had to edit UI of some application. No idea why developers went that way…

In Qt world all you had to do was launching Qt Designer, put some UI elements into window, apply some Layout elements and build your app. No need to deal with padding/margin settings etc cause library that for you.

In meantime Qt developers added QML as a new way to do UI for Qt applications. I ignored it’s existence until now…

Few days ago Michał Schulz did nice work on improving my Modland player. He also moved it’s UI from old Qt Designer one to QML.

Modland player with QML based UI

For now UI is hardcoded to 800x480. I have tried to make it scalable but have a feeling that QML is against me.

Look at Authors/Modules part. It is simple layout, right?

label
listView
label
listView

In Qt Designer UI I would select those four elements, put into GridLayout and it would scale properly. So I tried that for QML. Labels survived, listViews got 0x0 size.

And the only ‘design tool’ to edit QML is Qt Creator. Which gets fugly unstable once you try to play with QML designs…

So I looked at files describing UI. And you know what I found there? Old GTK nightmares… Positioning elements with pixels, sizes in pixels. Pixels! Not some magical “dp units”. There is no way to say “make this element 10em tall” like you can with CSS.

And it is not only with Modland player UI. Same it with QML examples…

WTH happened with Qt developers? Or was “QML is only for embedded devices, do not use on desktop” phrase got removed from documentation by mistake?

The story of Qt/AArch64 patching

2014-01-20T18:16:00+01:00

In over a year of my work as AArch64 porter I saw a lot of patches. But Qt one has the most interesting history.

Around year ago when I was building whatever possible during my Linaro work we got to the point when Qt jumped into a queue. Build failed but fixing was quite easy — all I had to do was to take “webkitgtk” patch written by Riku Voipio and apply it to Qt 4. Resulting file landed in “meta-aarch64” layer of OpenEmbedded and is still there.

Time passed. More common distributions like Debian, Fedora, OpenSUSE, Ubuntu (alphabetical order) started working on their AArch64 ports. And one day Fedora and Ubuntu started working on building Qt 4. I do not know who wrote QAtomic stuff but I saw few versions/iterations of it and it took me quite long time (first on model, then on real hardware) to get it fully working in Fedora — used Ubuntu version of patches.

Up to this moment it was over 9 months and still no upstreaming was done. So one day I decided to go for it and opened QTBUG #35442. Then reopened issue #33 in “double-conversion” project (which is used in few places in Qt) as they got good fix and merged wrong one (but it is fixed now). For that one I opened a request to update to newer version of “double-conversion” as QTBUG #35528.

But story did not end there. As Qt 4 development is more or less ended I was asked to provide fixes for Qt 5. Took me a while. Had to create a graph of build time dependencies between Qt 5 components (had to break few in meantime) and slowly module after module I got most of it built.

There were 3 components which required patching:

qtdeclarative (issue #33, QTBUG #35528)
qtscript (WebKit related, sent by Riku Voipio as Qt change #74927)
qtwebkit (sent as Qt change #74851)

First one is solved upstream and waits for Qt guys. I was told that 5.3 will get it updated. Second one is already reviewed and merged. Last one left and here is a problem as it looks like the only person who does QtWebKit code reviews is Allan Sandfeld Jensen but he can not review code he sent. I am not able to do that due to Qt Contributor License Agreement which needs to be signed and (due to legal stuff) I can not do that.

So how it looks now? I would say that quite good. One 3rd party project needs update (in two places of Qt 5) and one patch needs to get through code review. I still need to send package updates to Fedora bug tracker. Ubuntu will need to merge patches when they move to 5.2 version.

Is this the end of Maemo5?

2010-12-07T18:09:00+01:00

Some time ago I stopped following Maemo news. For me N900 became “just a phone” which I used for calls, checking email in crappy Modest, browsing web from time to time and to read Twitter (if any application for it works) or Facebook (by web browser cause there are no apps for it).

But recently I got one tweet which pointed me to “State of Maemo” post. For me it looks like Nokia decided to finally abandon sinking ship and leave Nokia N900 users alone. Qt will probably get some updates to show that they care about cross platform support. How many MeeGo Qt apps will work on Maemo5? No one knows probably but one thing is sure — they will have to be recompiled because Harmattan will be hard-float (confirmed by Nokia developer during UDS-N). But for rest community will have to care about.

OK, there was told that there are “ideas about opening various pieces of Maemo source code that are still closed” but what it will be? No one knows. I would like to get Calendar opened but when it will happen I will probably do not have N900 anymore…

And today I read total “please ignore our ,but ignored by us, platform” message:

Last week we spoke with Nokia. We were actively discouraged from developing for Maemo any further. There are lots of things we love about Maemo, including an awesome user community so we’re disappointed to see it EOL’d. It’s frustrating to have put so much effort into an app only to see the platform it’s on be terminated. Whether we reappear on MeeGo — the successor to Maemo — depends in part on Nokia. In the mean time, our conversation with Nokia has led us to deprioritize the update we were working on, though no final decision has been made yet as to whether or not it’ll ship. I’ll keep you posted.

Somebody wants to buy my N900? I am going to move to Android because this looks like a platform where OS vendor care at least on some of devices by providing system upgrades. And there are communities which provide updates for abandoned devices. And no, I do not plan to buy device running MeeGo — enough money spent on Nokia devices.

Is designing UI simple with Qt?

2010-09-17T17:19:00+02:00

I use Qt on my devices since my first LinuxPDA: Sharp Zaurus SL5000 on which I used OpenZaurus with OPIE as primary environment. It was based on Qt/Embedded 2.3.x and was looking ok. UI of most applications work properly in both portrait and landscape modes, adapted to size of fonts (I used smaller then default ones).

Then Zaurus c760 arrived at my place and I did some UI code tweaks to make everything looking better on VGA screen (not that it looked wrong — I just improved few things). At that time I had nearly every Zaurus model in hands and took care to make all looks proper in both orientations.

From time to time I was also playing with 3rdparty applications to adapt them to resolutions higher then QVGA (which was sort of standard in palmtops of that era). Usually loading UI files into Qt Designer and reordering them or adding layouts helped. One of them was Mileage which required adding huge amount of layout elements just to make it look properly (all elements were put as X,Y positions originally).

Some time later I moved to GTK/X11 based environments on portable devices and later my cellphones took PDA place.

But with Nokia N900 I decided to go back to programming with Qt - 4.6 version this time. First was my module player (which I probably never end) and some time later I decided to play a bit with Vexed released by Paul Romanchenko (rmrfchik on #maemo) where I reorganized UI a bit, added portrait support and did few other tweaks.

But then I switched to ApMeFo and while idea of application is good the UI is disaster:

tabs in main window
lack of portrait support
unusable UI when forced to portrait mode
use of non standard button sizes
use of non standard font sizes

And sources lacked UI files… So one day I decided that it will be good occasion to learn something new. Author was not responding to my sources request so I launched Qt Designer and started to recreate UI from scratch — using existing sources as information what kind of widgets were used. Took me some time but I got new, a bit improved UI which even worked in portrait mode:

UI in portrait mode

But it still was not what I wanted. It still had tabs and small buttons… First I got rid of tabs:

UI without tabs

Rest of functionality was moved to menu and separate window:

separate window

I was not too proud of it. OK, it looked better, I even changed some non-UI code but it still was not what I wanted to achieve. But at least I had something what I could give to users for testing.

How does it look now? Let me show not yet published version:

First main window — all buttons are finger friendly. I also grouped them a bit — it is visible in portrait mode which is also great when user want to re-order items.

Main window

Main window in portrait

Dialog to select applications to add got some changes too. It is maybe not conform with UI style guide (OK not under but on right) but it gave me extra line in list widget. Think of multi selection…

Add application dialog

As you see (de)activation and folders are now in menu. (De)Activation has also Yes/No requesters :)

Folders window is place which needs lot of work. Only delete works now (also with Yes/No requester).

Folders window

Folders window in portrait

List of things to do is long as users suggested many things. I probably will not add most of them because so far I did not checked how exactly ApMeFo works but once I will read rest of source code I think that something good will come from it.

And is designing UI simple with Qt? I think that it is — developer does not have to worry what kind of paddings are needed to be used, how to place widgets to make UI conform to style guide rules etc. Once you do design with layout elements application adapts itself to what is available.

Qt under Maemo is pain to develop with

2010-02-22T17:29:00+01:00

I have my own Protracker module player written for Maemo5. I used Qt because I am familiar with it and like it. But Maemo5 makes simple things harder…

First thing: which version of Qt? Yes — there are two of them:

4.5.3 which was ported by community, does not follow Maemo5 look & feel but is present on each Nokia N900 by default
4.6 ported by Nokia, follows Maemo5 look & feel as much as possible but present only in extras-devel repository

I used Qt 4.6 because of proper look and working Phonon.

Second problem: moving API. Ok, I know: it is extras-devel so not safe for devices but why I have to rebuild application after each “apt-get update/upgrade” cycle? First it was removal of QMaemo5KineticScroller, then rotation code changed.

Rotation is 3rd problem. In recent packages there is support for automatic rotation without any code other then setting window attribute for it. It is even documented. But it does not work — even in official example. From one commit to qt/maemo5 repo I got a feeling that automatic rotation needs to wait for next firmware update :(

Good thing is that my application is small so adapting to changes takes small amount of time. And I hope that PR1.2 will finally give working Qt without many changes.