Canonical Voices

Posts tagged with 'qt'


Movin' on...

A year has gone by since I started work with Canonical. As it turns out, I must be on my way. Where to? Not real sure at this moment, there seems plenty of companies using Qt & QML these days. \0/

But saying that, I am open to suggestions. LinkedIn
Plenty of IoT and devices using sensors around. Heck, even Moto Z phone has some great uses for sensor gestures similar to what I wrote for QtSensors while I was at Nokia.

But a lack of companies that allow freelance or remote work. The last few years I have worked remotely doing work for Jolla and Canonical. Both fantastic companies to work for, which really have it together for working remotely.

I am still surprised that only a handful of companies regularly allow remote work. I do not miss the stuffy non window opening offices and the long daily commute, which sometimes means riding a motorcycle through hail! (I do not suggest this for anyone)

Of course, I am still maintainer for QtSensors, QtSystemInfo for the Qt Project, and Sensor Framework for Mer, and always dreaming up new ways to use sensors. Still keeping tabs on QtNetwork bearer classes.

Although I had to send back the Canonical devices, I still have Ubuntu on my Nexus 4. I still have my Jolla phones and tablet.

That said, I still have this blog here, and besides spending my time looking for a new programming gig, I am (always) preparing to release a new album.
and always willing to work with anyone needing music/audio/soundtrack work.

Read more

Like it says on the Intel IoT developer site, "Without sensors, there's no IoT".

Because I am the maintainer of QtSensors, I like to inquire about  people's use of sensors and if they use QtSensors. Over the years, I have heard quite often something like, 'Qt is thought of as a UI framework'. *sigh*
But Qt is more than just a UI framework and it's use is not dependent on widgets or declarative wizardry. It is used in quite a few middleware components without UI elements. One of those middleware frameworks is Sensor Framework.

Sensor framework is a daemon that uses a plugin system written using Qt for reading various sensors such as accelerometer or light sensors. It was originally developed by Nokia for Harmattan and ran on the N9. It was also used in MeeGo and later included in the Mer Project and on Jolla phones and the ill fated tablet. So it has been released onto a few commercial products.

We looked at it when I was working at Nokia on the project that I still cannot name, but we had decided we would come up with our own solution. Looking back, this was the wrong decision, we should have taken the already proven sensor framework and ran with that. Why? Because it existed and works.

I started maintaining it when I was a privateer (contractor) developer for Jolla. No one else had touched it for some time so I grabbed the few not yet merged bug fixes and added support for libhybris/android libhardware adaptors.

Sensor Framework has support for multiple clients with down sampling for different data rates. It uses dbus for control lines (to start and stop, etc) but sends data through a socket. It also has a working backend in QtSensors.

I noticed that Ubuntu's Unity does nothing to respond when I put this into "tablet mode". I have to manually open the virtual keyboard among other things.

So I thought I could use sensorfw on my Dell 2 in 1. It's one of those converged laptop/tablet devices. It has a few sensors - accelerometer, gyroscope, magnetometer, and lid sensors. One problem... sensorfw does not support lid sensors, or a few other sensors that are around today in IoT (which I will add a bit later). Lid "sensor" might be a bit of a misnomer, as they could be switches but I'd like to think it is more like a hal effect sensor that uses magnets. In any case there are event nodes to use.

First one I chose is to add the lid sensor - to detect when this machine is put into tablet mode, so the UI can better deal with it.

I also noticed that this kernel has support for iio sensor interface for the accel and gyro. Sensorfw only supports sysfs, evdev and hybris interfaces, so I also wanted to add support for that.

I worked on adding iio support first. Well... really just wrote a sensor adaptor plugin. My plugin supports accelerometer, gyroscope and magnetometer, which this device seems to have. I will expand this to support other sensors later, as well as clean it up a bit.

Thanks to QtSensors sensor framework backend, I can make a UI app change with the orientation and lid changes. Better yet, I can create a game that uses accelerometer data like a marble maze game. Or I can upload the data to one of those Node.js data visualization web apps.

And since sensor framework is opensource, others can as well.

Read more

Sensors are an important part of IoT. Phones, robots and drones all have a slurry of sensors. Sensor chips are everywhere, doing all kinds of jobs to help and entertain us. Modern games and game consoles can thank sensors for some wonderfully active games.

Since I became involved with sensors and wrote QtSensorGestures as part of the QtSensors team at Nokia, sensors have only gotten cheaper and more prolific.

I used Ubuntu Server, snappy, a raspberry pi 3, and the senseHAT sensor board to create a senseHAT sensors snap. Of course, this currently only runs in devmode on raspberry pi3 (and pi2 as well) .

To future proof this, I wanted to get sensor data all the way up to QtSensors, for future QML access.

I now work at Canonical. Snappy is new and still in heavy development so I did run into a few issues. First up was QFactoryLoader which finds and loads plugins, was not looking in the correct spot. For some reason, it uses $SNAP/usr/bin as it's QT_PLUGIN_PATH. I got around this for now by using a wrapper script and setting QT_PLUGIN_PATH to $SNAP/usr/lib/arm-linux-gnueabihf/qt5/plugins

Second issue was that QSensorManager could not see it's configuration file in /etc/xdg/QtProject which is not accessible to a snap. So I used the wrapper script to set up  XDG_CONFIG_DIRS as $SNAP/etc/xdg

[NOTE] I just discovered there is a part named "qt5conf" that can be used to setup Qt's env vars by using the included command qt5-launch  to run your snap's commands.

Since there is no libhybris in Ubuntu Core, I had to decide what QtSensor backend to use. I could have used sensorfw, or maybe iio-sensor-proxy but RTIMULib already worked for senseHAT. It was easier to write a QtSensors plugin that used RTIMULib, as opposed to adding it into sensorfw. iio-sensor-proxy is more for laptop like machines and lacks many sensors.
RTIMULib uses a configuration file that needs to be in a writable area, to hold additional device specific calibration data. Luckily, one of it's functions takes a directory path to look in. Since I was creating the plugin, I made it use a new variable SENSEHAT_CONFIG_DIR so I could then set that up in the wrapper script.

This also runs in confinement without devmode, but involves a simple sensors snapd interface.
One of the issues I can already see with this is that there are a myriad ways of accessing the sensors. Different kernel interfaces - iio,  sysfs, evdev, different middleware - android SensorManager/hybris, libhardware/hybris, sensorfw and others either I cannot speak of or do not know about.

Once the snap goes through a review, it will live here, but for now, there is working code is at my sensehat repo.

Next up to snapify, the Matrix Creator sensor array! Perhaps I can use my sensorfw snap or iio-sensor-proxy snap for that.

Read more

In the ubuntu download manager we are using the new connection style syntax so that if there are errors in the signal connections we will be notified at compile time. However, in recent versions of udm we have noticed that the udm tests that ensure that the qt signals are emitted correctly have started failing randomly in the build servers.

As it can be seen in the following build logs the compilation does finish with no errors but the tests raise errors at runtime (an assert was added for each of the connect calls in the project):

Some of the errors between the diff archs are the same but this feels like a coincidence. The unity-scope-click package project has had the same issue and has solved it in the following way:

    // NOTE: using SIGNAL/SLOT macros here because new-style
    // connections are flaky on ARM.
    c = connect(impl->, SIGNAL(downloadCreated(Download*)),
                this, SLOT(handleDownloadCreated(Download*)));
    if (!c) {
        qDebug() << "failed to connect to systemDownloadManager::downloadCreated";

I am not the only one that have encoutered this bug within canonical (check out this bug). Apprently -Bsymbolic breaks PMF (Pointer to Member Function) comparison under ARM as it was reported in linaro. As it is explained in the Linaro mailing list a workaround to this (since the correct way would be to fix the linker) is to build with PIE support. The Qt guys have decided to drop -Bsymbolic* on anything but x86 and x86-64. I hope all this info help others that might find the same problem.

Read more
Timo Jyrinki

Qt 5.2.1 in Ubuntu

Ubuntu running Qt 5.2.1
Ubuntu running Qt 5.2.1
Qt 5.2.1 landed in Ubuntu 14.04 LTS last Friday, hooray! Making it into a drop-in replacement for Qt 5.0.2 was not trivial. Because of the qreal change, it was decided to rebuild everything against the new Qt, so it was an all at once approach involving roughly 130 source packages while the parts were moving constantly. The landing last week meant pushing to archives around three thousand binary packages - counting all six architectures - with the total size of closer to 10 gigabytes.

The new Qt brings performance and features to base future work on, and is a solid base for the future of Ubuntu. You may be interested in the release notes for Qt 5.2.0 and 5.2.1. The Ubuntu SDK got updated to Qt Creator 3.0.1 + new Ubuntu plugin at the same time, although updates for the older Ubuntu releases is a work in progress by the SDK Team.

How We Got Here

Throughout the last few months before the last joint push, I filed tens of tagged bugs. For most of that time I was interested only in build and unit test results, since even tracking those was quite a task. I offered simple fixes here and there myself, if I found out a fix.

I created automated Launchpad recipe builds for over 80 packages that rely on Qt 5 in Ubuntu. Meanwhile I also kept on updating the Qt packaging for its 20+ source packages and tried to stay on top of Debian's and upstream's changes.

Parallel to this work, some like the Unity 8 and UI Toolkit developers started experimenting with my Qt 5.2 PPA. It turned out the rewritten QML engine in Qt 5.2 - V4 - was not entirely stable when 5.2.0 was released, so they worked together with upstream on fixes. It was only after 5.2.1 release that it could be said that V4 worked well enough for Unity 8. Known issues like these slowed down the start of full-blown testing.

Then everything built, unit tests passed, most integration tests passed and things seemed mostly to work. We had automated autopilot integration testing runs. The apps team tested through all of the app store to find out whether some needed fixes - most were fine without changes. On top of the found autopilot test failures and other app issues, manual testing found a few more bugs

Some critical pieces of software
like Sudoku needed small fixing
Finally last Thursday it was decided to push Qt in, with a belief that the remaining issues had fixes in branches or not blockers. It turned out the real deployment of Qt revealed a couple of more problems, and some new issues were raised to be blockers, and not all of the believed fixes were really fixing the bugs. So it was not a complete success. Considering the complexity of the landing, it was an adequate accomplishment however.

Specific Issues

Throughout this exercise I bumped into more obstacles that I can remember, but those included:
  • Not all of the packages had seen updates for months or for example since last summer, and since I needed to rebuild everything I found out various problems that were not related to Qt 5.2
  • Unrelated changes during 14.04 development broke packages - like one wouldn't immediately think a gtkdoc update would break a package using Qt
  • Syncing packaging with Debian is GOOD, and the fixes from Debian were likewise excellent and needed, but some changes there had effects on our wide-spread Qt 5 usage, like the mkspecs directory move
  • xvfb used to run unit tests needed parameters updated in most packages because of OpenGL changes in Qt
  • arm64 and ppc64el were late to be added to the landing PPA. Fixing those archs up was quite a last minute effort and needed to continue after landing by the porters. On the plus side, with Qt 5.2's V4 working on those archs unlike Qt 5.0's V8 based Qt Declarative, a majority of Unity 8 dependencies are now already available for 64-bit ARM and PowerPC!
  • While Qt was being prepared the 100 other packages kept on changing, and I needed to keep on top of all of it, especially during the final landing phase that lasted for two weeks. During it, there was no total control of "locking" packages into Qt 5.2 transition, so for the 20+ manual uploads I simply needed to keep track of whether something changed in the distribution and accommodate.
One issue related to the last one was that some things needed were in progress at the time. There was no support for automated AP test running using a PPA. There was also no support on building images. If migration to Ubuntu Touch landing process (CI Train, a middle point on the way to CI Airlines) had been completed for all the packages earlier, handling the locking would have been clearer, and the "trunk passes all integration tests too" would have prevented "trunk seemingly got broken" situations I ended up since I was using bzr trunks everywhere.

Qt 5.3?

We are near to having a promoted Ubuntu image for the mobile users using Qt 5.2, if no new issues pop up. Ubuntu 14.04 LTS will be released in a month to the joy of desktop and mobile users alike.

It was discussed during the vUDS that Qt 5.3.x would be likely Qt version for the next cycle, to be on the more conservative side this time. It's not entirely wrong to say we should have migrated to Qt 5.1 in the beginning of this cycle and only consider 5.2. With 5.0 in use with known issues, we almost had to switch to 5.2.

Kubuntu will join the Qt 5 users next cycle, so it's no longer only Ubuntu deciding the version of Qt. Hopefully there can be a joint agreement, but in the worst case Ubuntu will need a separate Qt version packaged.

Read more

This is a small tip for those thos want to use QTest and Google Mock. To ensure that the expectations are check at the end of the execution of the test function and that errors are correctly reported you have to check the expectaions manually and pass the results to a QVERIFY macro. The following examples should be good to get you started:

TestBaseDownload::testStartQueued() {
    QScopedPointer<MockDownload> down(
        new MockDownload(_id, _path, _isConfined, _rootPath, _url,
            _metadata, _headers));
    EXPECT_CALL(*, startDownload())

The important line to look at in the example is the following:


There we are passing the result of Mock::VerifyAndClearExpectations, where VerifyAndClearExpectations verifies and removes the expectations on a mocked object and returls a bool if it was successful. This way if the expectations are not met the QTest will fail.

For those interested in the error output it would be somthing of the following stype:

home/mandel/Canonical/udm/upload-interface/ubuntu-download-manager-tests/test_base_download.cpp:135: Failure
Mock function called more times than expected - returning directly.
    Function call: cancelDownload()
         Expected: to be never called
           Actual: called once - over-saturated and active
FAIL!  : TestBaseDownload::testCancelNotQueued() 'Mock::VerifyAndClearExpectations(' returned FALSE. ()
   Loc: [/home/mandel/Canonical/udm/upload-interface/ubuntu-download-manager-tests/test_base_download.cpp(139)]

Read more

They say there are two sides to every coin, and that holds true for the story of the history leading up to Jolla and it's Sailfish OS. The Jolla story usually starts out with Nokia, but it's really a convergence with Nokia as the center point.

This side of the story starts in Norway, not Finland. Oslo, in fact. Not with Nokia, but with a small company named Trolltech.

I won't start at the very beginning but skip to the part where I join in and include a bit about myself. It was 2001, I was writing a Qt based app called Gutenbrowser. I got an email from A. Kozak at Trolltech, makers of Qt. Saying that Sharp was planning to release a new PDA based on Qt, and wouldn't it be cool if Gutenbrowser would be ported to it? I replied, yes, but as I have no device it might be difficult. He replied back with a name/email of a guy that might be able to help. Sharp was putting on a Developer Symposium where they were going to announce the Zaurus and hand out devices to developers. I jumped at the chance.

It was in California. At that time I was in Colorado. Jason Perlow was working for Sharp at that time, and said he had an extra invite to the Developer symposium. WooHoo! The Zaurus was going to run a Qt based interface originally named QPE, later named Qtopia (and even later renamed Qt Extended). The sdk was released, so I downloaded it and started porting even before I had a device to test it on.

Qtopia was open source, and it was available for developers to tinker with, and put on other devices. There was a community project based on the open source Qtopia called Opie that I became involved with. That turned into me getting a job with Trolltech in Australia, where Qtopia was being developed, as the Qtopia Community Liaison, which luckily later somehow turned into a developer job.

Around the time that Nokia came out with the Maemo tablets, I was putting Qtopia on them. N770, N800, N810, and N900 all got the Qt/Qtopia treatment. (Not to mention the OpenMoko phones I did as well).

Then I was told to flash a Qtopia on an N810 because some Trolls were meeting with Nokia. That became two or three images I had to flash over the coarse of a few weeks. I knew something was up.

Around this time, one of the Brisbane developers (A. Kennedy, I'm looking at you!) had a Creative Friday project to make a dynamic user interface framework using xml. (Creative Friday was something Trolltech did that allowed developers to spend every Friday (unless impending doom of bug fixes/release) of their time on research projects) It was really quite fluid and there was a "prototype" interface running on that N810 as well. It only took a few lines of non c++ code to get dynamic UI's. This would have turned into what the next generation of Qtopia's interface would be made with. It was (and still is) quite amazing.

Then came the news that Nokia was buying Trolltech! Holy cow! A HUGE company that makes zillions of phones wanted to buy little ol' Trolltech. But they already had a Linux based interface - Maemo that was based on Gtk toolkit, and not Qt. WTH!?

Everyone speculated they wanted Trolltech for Qtopia. Wrong. Nokia wanted Qt, and decided to ditch Qtopia. We had a wake for the Qtopia event loop to say our good riddance. All of us in Brissie worried about our jobs.

So our little Trolltech got assimilated into this huge behemoth phone company from Finland. Or was it that Trolltech took over Nokia...? Nokia had plans for Qt that would provide a common toolkit for their massively popular Symbian and new Linux based phones.

The Brisbane office started working on creating the QtMobility API's. Yes, there are parts of Qtopia in QtMobility.

Meanwhile, that creative friday xml interface was still being worked on. It got canceled a few times and also revived a few. That eventually evolved into QML, and QtQuick.
Then came N9 and MeeGo, which was going to use this new fangled dynamic UI. MeeGo was also open source, and it's community version was called Mer and Nemo. Yes, there are parts of Qtopia in MeeGo.

The rest of the story is famous, or rather, infamous now. Nokia made redundant the people working on MeeGo. Later on, all of us Brisbane developers, QA and others were also made redundant. The rest of what I call the Trolltech entity got sold to Digia. The QA server room was packed up and shipped to Digia, who is doing a fantastic job of getting Qt Everywhere!

A few of those guys that were working on MeeGo got together and created a company called Jolla, and created a Linux based mobile OS based on Mer named Sailfish. Yes, there are a few Trolltech Trolls working for Jolla. and yes, there are parts of Qtopia in Sailfish.

Read more

You might have had the following error in your dbus daemon at some point and said to yoursefl WTF???

process 1288: arguments to dbus_message_set_error_name() were incorrect, assertion "error_name == NULL
   || _dbus_check_is_valid_error_name (error_name)" failed in file dbus-message.c line 2900.

Well, you are not the only one and I might be able to point you to the correct direction, your code is probably returnning a QDBusError that you created using the QDBusError::Other enum. The problem here is that the enum value your are using only indicates that the error name is not known and therefore cannot be match to a value in the QDBusError enum. When you use that enumerator the message created does have an incorrect name as follows:

QDBusMessage(type=Error, service="", error name="other", error message="msg", signature="", contents=() ) 

And “other” is, of course, not a valid DBus name and thefore the app crashes. Easies way to solve it, create a correct DBusError ;)

Read more

Ok, imaging that you are working with Qt 5 and using the new way to connect signals, lets for example say we are working with QNetworkReply and we want to have a slot for the QNetworkReply::error signals that takes a QNetworkReply::NetworkError, the way to do it is the following:

connect(_reply, static_cast<void(QNetworkReply::*)
        this, &MyClass::onNetworkError)

The static_cast is helping the compiler know what method (the signals or the actual method) you are talking about. I know, it is not nice at all but works at compile time better than getting a qWarning at runtime.

The problem is that without the help the compiler does not know what method error you are talking about :-/

Read more

I the last few months I have been working on the Ubuntu Download Manager, one of The Big Rocks of August. The u-d-m provide a dbus service that allows applications to request downloads to be performed, to such download requests it adds some nice features that a user on a mobile phone, and probably a desktop, is interested to have. Some of those features are:

  • Apparmor isolation per download. That means that only you application can interact with its downloads.
  • Pause/Resume downloads
  • Autodetect network connection.
  • WIFI only downloads.
  • Hash check support.
  • Allow downloads to be performed while an application has been paused or killed.
  • Group downloads, where a bunch of files are provided and the different downloads are performed as a single atomic operation.

A download might seem a simple action to perform, right? Well, as soon as you start supporting all the above a single download operation becomes a fairly complicated matter. The following is a state machine that identifies the states of a download that would support such features:


As you can see, it is a complicated matter and all these has to be tested and check by the QA team. By providing u-d-m (and later a client library to use approach in C and in the Ubuntu SDK, I’m terribly sorry but I did not have the time to finish it on time for the release) we are helping developers to perform simple downloads with robust code and do not worry about all the corner cases. Performing a download is as simple as requesting it and listen to the different signals. This kind of service is also provided by FirefoxOs, WEbOs and Tizan (but no in IOS or SailFish) but I believe we are doing a better job at exposing a richer API. Of course all this is open source and at least our friend at Jolla (and I really mean friends, I think they are doing an awesome work!!! and competition + collaboration is great).

In the following days I’ll be posting on hot to use the API via C, C++ and DBus.

Read more
Timo Jyrinki


I quite like the current status of Qt 5 in Debian and Ubuntu (the links are to the qtbase packages, there are ca. 15 other modules as well). Despite Qt 5 being bleeding edge and Ubuntu having had the need to use it before even the first stable release came out in December, the co-operation with Debian has gone well. Debian is now having the first Qt 5 uploads done to experimental and later on to unstable. My work contributed to pkg-kde git on the modules has been welcomed, and even though more work has been done there by others, there haven't been drastic changes that would cause too big transition problems on the Ubuntu side. It has of course helped to ask others what they want, like the whole usage of qtchooser. Now with Qt 5.0.2 I've been able to mostly re-sync all newer changes / fixes to my packaging from Debian to Ubuntu and vice versa.

There will remain some delta, as pkg-kde plans to ask for a complete transition to qtchooser so that all Qt using packages would declare the Qt version either by QT_SELECT environment variable (preferable) or a package dependency (qt5-default or qt4-default). As a temporary change related to that, Debian will have a debhelper modification that defaults QT_SELECT to qt4 for the duration of the transition. Meanwhile, Ubuntu already shipped the 13.04 release with Qt 5, and a shortcut was taken there instead to prevent any Qt 4 package breakage. However, after the transition period in Debian is over, that small delta can again be removed.

I will also need to continue pushing any useful packaging I do to Debian. I pushed qtimageformats and qtdoc last week, but I know I'm still behind with some "possibly interesting" git snapshot modules like qtsensors and qtpim.


More delta exists in the form of multiple patches related to the recent Ubuntu Touch efforts. I do not think they are of immediate interest to Debian – let's start packaging Qt 5 apps to Debian first. However, about all of those patches have already been upstreamed to be part of Qt 5.1 or Qt 5.2, or will be later on. Some already were for 5.0.2.

A couple of months ago Ubuntu did have some patches hanging around with no clear author information. This was a result of the heated preparation for the Ubuntu Touch launches, and the fact that patches flew (too) quickly in place into various PPA:s. I started hunting down the authors, and the situation turned out to be better than I thought. About half of the patches were already upstreamed, and work on properly upstreaming the other ones was swiftly started after my initial contact. Proper DEP3 fields do help understanding the overall situation. There are now 10 Canonical individuals in the upstream group of contributors, and in the last week's sprint it turned out more people will be joining them to upstream their future patches.

Nowadays about all the requests I get for including patches from developers are stuff that was already upstreamed, like the XEmbed support in qtbase. This is how it should be.

One big patch still being Ubuntu only is the Unity appmenu support. There was a temporary solution for 13.04 that forward-ported the Qt 4 way of doing it. This will be however removed from the first 13.10 ('saucy') upload, as it's not upstreamable (the old way of supporting Unity appmenus was deliberately dropped from Qt 5). A re-implementation via QPA plugin support is on its way, but it may be that the development version users will be without appmenu support for some duration. Another big patch is related to qtwebkit's device pixel ratio, which will need to be fixed. Apart from these two areas of work that need to be followed through, patches situation is quite nice as mentioned.


Free software will do world domination, and I'm happy to be part of it.

Read more
Timo Jyrinki

I'd like to modify my discussion comment and earlier thoughts into a short blog post touching only some of the technical concerns voiced, and my opinion to those.

Claim (my version): Ubuntu/Canonical is going the "Google route" to become another Android, while Android has not benefited the Linux ecosystem in any way, forking everything

Firstly, Ubuntu is open to development and community for also mobile and tablet - Android has none of that, just code drops that get modded. (yes, some people have a problem with CLA like Canonical's or Qt's, I have no problem with those - let's keep that discussion elsewhere). Ubuntu contributes back to Debian and upstream projects like Qt - those upstream projects it's not upstream of itself. There are not too many free software mobile UIs for example. SHR has some E17 apps, Nemo Mobile a handful of Qt apps and so on.

Secondly, I disagree about Android - even in its current shape and after creating everything from scratch with mobile on mind, Android has done tremendous things for the free software community, kernel development, mobile device driver and making things like Replicant possible. If those aren't directly seen on the desktop side, that's because it's not the desktop and most free software desktop users don't use free software mobile products (usually at most a vendor provided Android).

I feel people get too attached to software projects or even the desktop in general. The money to pay desktop has traditionally largely come from the server. As a discussion-heating example Wayland has been a great promise for 5 years and continues to be, yet no products use it (software products like distributions or hardware+software products). That's not a problem per se for a great and ambitious project, but it means no interested party has taken it to create products. I was very excited about Gallium3D and Wayland in 2008, but somewhat optimistic in believing they would conquer the world in one or two years. In perspective, I've always seen the "version staring" a common habit in enthusiasts me included. I think it extents to "shiny development projects that should be taken into production use immediately".

The Nokia N9 triumphs all other 2011 mobile phones in general and even the current user interfaces like iOS, Android and Windows Phone in general usability ideas (if only it'd run Cortex-A15 instead of OMAP3..). It uses and Qt 4.7. Jolla's plans for their first phone at the end of this year? Qt 4.8, no Wayland. Like N9 which otherwise had unfortunate fate, I hope Jolla will sell millions of free software wielding products to the masses. The biggest problem with is, though, the drivers, generally zero support from vendors so hard to make products. Hooking into Android EGL drivers and building on top of that seems a good compromise at the moment. Note that from product creation point of view it's not the non-shininess of that IMHO is the blocker. Wayland and Mir may help on the driver side.

I want products!

I'd love to see more push to have actual products on the market, since otherwise we don't get free software to the masses. If Mir helps Ubuntu to do that in one year, fine (I don't know how it's going to be). Yes Mir is a new shiny project, but it's a very product/target oriented project one. If Android would be open as a project, it wouldn't hurt - other than feelings attached to the other projects especially by the core developers and fans of those - if it was the superior alternative from product creation perspective making all of, upstart, systemd, Wayland, Pulseaudio, D-Bus, glibc less interesting to product creators while even more interest would go to Android. It's not so now, Android is not an open project in any sense, even though still beneficial for free software. Ubuntu will keep using a lot more of the traditional stack anyway than Android (which also just got rid of BlueZ), but I have zero problem of changing any of the components if it's visioned to be required to get finished, ready to use products out. IMHO the key is to get products out, and I hope all the parties manage to do that.

Of the traditional GNU/Linux desktop distributions only Ubuntu seems to be adapting for the mobile in large steps at the moment. The other distributions in the mobile playing field are: (Android/)Replicant, Mer/Sailfish, Firefox OS, Tizen, added with OpenEmbedded based distributions like SHR. Have you used those on a daily basis on your devices? I believe you should. I think KDE will bring with its Plasma Active - currently focusing on building on top of Mer - mobile power to the traditional GNU/Linux distributions, but otherwise it's all up to the new players - and Ubuntu.

Like many know, I used Debian exclusively on my primary phone for ca. two years before switching mostly to N9. During all that time, I already pondered why people and distributions are so focused on x86 and desktop. And the reason is that that's what their history is, and I stared at the wrong place - desktop distributions. I dismissed Android and some of the small newcomers in the mobile distro playing field, but it seems that big changes are needed to not need completely new players. I think Ubuntu is on the completely right track to both benefit from the history and adapt for the future. I still hope more developers to Debian Mobile, though!! Debian should be the universal operating system after all.

Disclaimer: I'm an Ubuntu community person from 2004, Debian Developer since 2008 and a contractor for Canonical for ca. 1 year. My opinions haven't changed during the 1 year, but I've learned a lot more of how free software is loved at Canonical despite critics.

Read more

I have recently been doing some work with Qt and DBus and I got stuck a little on how to correctly send a {sv} over DBus. Either my google-fu is terrible or there are not many examples on how to do this, therefore here is a small static method that will return a {sv} that can be send via DBus without getting a wrong parameters error:

typedef QHash DBusStringHash;
class DBusHelper : public QObject
    static int DBUS_STRING_MAP_ID;
    explicit DBusHelper(QObject *parent = 0);
    static class _init
                // diff actions to init
                DBUS_STRING_MAP_ID = QMetaType::type("DBusStringHash");
    } _initializer;
    static QVariant getVariant(DBusStringHash hash);
#endif // DBUS_HELPER_H
// required for the init
int DBusHelper::DBUS_STRING_MAP_ID = 0;
DBusHelper::_init DBusHelper::_initializer;
DBusHelper::DBusHelper(QObject *parent) :
QVariant DBusHelper::getVariant(DBusStringHash hash)
    return QVariant(DBUS_STRING_MAP_ID, &amp;hash);

I added the init trick so that there is no need to manually register the types. I hope it helps!

Read more

motion sensor gestures

It's been quite a bit of time since I blogged about anything. No longer able to post to the official Qt Labs blog, so I will post here, and maybe it will get picked up to a wider audience.

It's been about 60 days since my last day at the Nokia office In Brisbane, Australia. My days are now full of house duties, kids, recording music, and looking for appropriate workage.

Blatant self promotion

I have been trying to keep my chops up, taking a short contract doing some desktopy work with Qt. But also keeping up with the Mer and Nemo projects.

We have been working on refactoring the Qt 5 QSensor qml API, removing the old qt-mobility stuff and merging the two imports.

As well, I will, in the near future be adding a QFreeFall sensor that detects when a device is freefalling, and a Wii controller sensor plugin to drive the normal motion QSensors and well as some of the QSensorGestures.

I have done the easily possible, and back ported QSensorGesture and friends to Qt 4, so projects such as Mer/Nemo/Jolla, as well as the Blackberry 10 projects could use some cool sensor gestures API.

When most people think of gesture recognition, they think of the touch sensor. Within Qt, this would be the QGesture classes. They also think about using the image sensor to decipher gestures through a computer vision API such as openCV.
and although I would like to extend QSensorGesture to include the openCV and touch sensors techniques, this is really about existing device motion gestures.

Things such as the obvious gesture of 'shake' - when you shake your phone/tablet, your audio playlist gets randomized. But it can be extended to other gestures as well.

QSensors include the qtsensors gesture recognition plugin, that includes such gestures as whip, shake, pickup, twist, cover, hover, turnover and slam.

The above url shows about how to perform these gestures.

These are simple ad-hock gesture recognizers, and do not verge into the more robust and technically challenging HMM realm of recognizers.

Nor is it currently possible for a user to create their own gestures and use them. I'd planned on doing this at my day job, but someone thought it better I needed to take my own time doing them. These are still on my todo list.

Of course, the backport isn't in the official Qt Mobility repo until becomes a part of the qt-project, but I believe that is only a matter of time and resources.

In my next blog, I will demonstrate the use of motion sensor gestures and the advantages that they might bring to a mobile UX.

Read more
Timo Jyrinki

OpenPhoenux GTA04

Postman was on a kind mood yesterday. My OpenPhoenux GTA04 arrived! I had my newer Neo FreeRunner upgraded via the service from Golden Delicious.

First, something rare to behold in phones nowadays - Made in Bavaria:

As a sidenote, also rare now - my Nokia N9 is one of the last phones that had this:

It's sad that's now a thing of the past for both hardware assembly and software! But that's just a hint for new companies to step in.

But back to GTA04 - a quick boot to the pre-installed Debian w/ LXDE:

And then as a shortcut unpacked and booted into QtMoko (well, it's also Debian) instead to test that phone functionality also works - and it does:

Next up: brewing something of my own!

Read more

Testing is hugely important to us at Canonical. We all strive to have Ubuntu reliable, consistent and fast. But we’re human, and we make mistakes. Sometimes a bugfix will break something else, and for something as complex as a desktop shell, it’s easy to miss these breakages. While manual tests can help reduce these regressions, realistically we need an automated system to emulate the users inputs and verify our software works as it should – and scream bloody murder if it doesn’t!

In Unity 2D (my project!), we have just introduced an automated User Experience testing system, based on a test framework called Testability Driver (I’ll just call it ‘Testability’ from now on). First off, a clarification:

Testability is for Qt-based applications only!

A limitation: yes, but this requirement comes with a great reward: Testability allows inspection of the tree of QObjects in a Qt application while it is running!

It can read and write object properties, call methods and slots, verify signals are emitted, as well as fake mouse/keyboard/gesture inputs, grab visual outputs, and measure performance.

And best of all, Testability is open source and maintained by Nokia! That means everyone can run and contribute tests!</p>
            <a href=Read more

Timo Jyrinki

Almost forgot to post this. My mobile phones running free software in photos. From left to right:

All of that software running on the devices is more or less free software, with Harmattan obviously being by far the least free, especially applications, but still better than any other on-the-shelf phone software *), and the others being 99% or "Ubuntu like" free ie. possibly with firmware and a few driver exceptions. N9 needs some bootloader work still before Nemo, Debian, Ubuntu etc. can be run there. I've collected a few things about N9 from this point of view at a wiki page.
*) Not sure about every Android phone, but Android is not openly developed anyway so it's hardly a similar free software project such as projects or Qt

I gave my N900 away now since obviously I cannot make full use of each one of these. I'm multi-SIMming my N9 and the GTA02a7 Neo FreeRunner for daily use, while the other FreeRunner and N950 are purely for tinkering related purposes. The development FreeRunner will get on upgrade to GTA04 once it's available, and then hopefully that can be made into a daily usable phone as well.

By the way, see you in FSCONS in Gothenburg next weekend. Even rms will be there, which is always interesting of course :)

Read more

UDS is here again. Tomorrow another week packed with content that will define the plans for a new Ubuntu LTS release will start, and this time around application development will be a prominent topic.

So for all of you interested in helping and being part of the effort of making Ubuntu a platform of choice for application developers, here’s a quick list with an overview of the sessions we’ve got in store this week.

Remember you can register your interest in sessions you want to attend or keep up to date with by using the Subscribe link on each session’s blueprint. The links in the list below will take you to the blueprints used to define the specifications for each feature or goal. You can also check out the full UDS schedule.

So, without further ado, here’s the list of app development sessions:

Oh, and don’t miss the Application development and the Qt keynotes on Tuesday

See you all there!

Read more
Timo Jyrinki

The MeeGo community is frustrated with the news of the MeeGo brand being abandoned. Some are understandably angry or otherwise not happy about how Linux Foundation, Intel handled the Tizen announcement and community in general - or more like how they didn't handle it at all. Last week Openmind 2011 happened to be arranged in Tampere on the very same day as Tizen announcement came alive. It was good in the way that it lead to the fact that Nomovok's CEO Pasi Nieminen was able to initiate the "Reigniting MeeGo" session not just by talking vague things about future, but actually about the process which led to Tizen and the unfortunately brief initial PR about it. Pasi is intense on emphasizing the quality and role of Qt in Tizen as well, even though officially Tizen is all about HTML5 and apparently from Samsung's part at least EFL is provided as a native toolkit. However, the promise of Tizen compared to MeeGo is reportedly that the toolkit is not specified in compliancy documents, so HTML5 with WAC is the main/only "3rd party apps" layer whereas others can be offered case-by-case. This means that unlike before, the underlying system can be built on top of practically any distribution (theoretically) and using whatever toolkits and other techniques wanted. Obviously the "Nordic System Integrators" are probably all very keen of using Qt to produce more of Nokia N9 quality user experiences in various products.

Taking the corporate hat off, I as a community member am also puzzled. The only reason I was not completely blown by the news was that I didn't yet manage to get involved in MeeGo community on a daily basis, since I'm involved with a dozen communities already. Instead I've been more like scratching the surface with MeeGo Network Finland meetings, IRC activity, OBS usage for building a few apps for MeeGo Harmattan and MeeGo proper etc. But I can somewhat understand how people like Jarkko Moilanen from meego-fi feel. They have given a _lot_ to the MeeGo community and brand, all taken away without hearing or pre-notice.

So where to now for MeeGo community? Tizen is one obvious choice. However, for all the talks that even I started this post with, Tizen is still vaporware today, and the dislike of how community is being treated might make it easy to consider other options. Also, if Tizen's reference implementation has lesser meaning, it might also mean less to actually be "in" the Tizen community than in MeeGo. I met Jos Poortvliet at Openmind, and he invited people to openSUSE. There is a lot of common ground with MeeGo and openSUSE - strong OBS usage, RPM packaging, community side focused on KDE and therefore Qt.

I would like to now point similarly to Debian! If one is tired about corporate interests and not listening to community, there is no match for Debian's 15+ years history, purely volunteer based, trust based organization, and first of all scope. While openSUSE has traditionally focused on desktop (even though like Jos pointed out they are open to all new contributions and projects), Debian has always had the "universal" scope, ie. no boundaries besides producing free software operating system for various purposes. There are over 10 architectures maintained at the moment, including the ARM (different ports for ARMv4 and hard-float ARMv7) and x86 from MeeGo world. There are even alternative kernels to Linux, mainly the GNU/kFreeBSD port. There are multiple relevant plans and projects like the Smartphones wiki area, most noticeably Debian on Neo FreeRunner. I have run Debian on my primary mobile phone for over 2.5 years, although now in the recent months I've had dual-SIM in my Nokia N950 as well (Debian not yet running on Nokia N950 or Nokia N9 - but it can and will be done!).

What Debian may lack in both good and bad is corporate funding, if you don't count the still quite respectful contributions from Ubuntu to Debian (it's in Ubuntu's interests to contribute as much possible back to Debian, so that the delta remains small). For each and every aspect, it needs a volunteer - there are a thousand volunteer Debian Developers, and at least a double of that of people without the official DD status but who still maintain a package or two among the 25000+ packages in Debian. That means also that one my find it more lucrative to join a project that has paid people to do some of the "boring parts", more of fancy web tools, including for bug handling and build systems like the OBS (which I do love by the way). On the other hand, there is no other project in my opinion where what you do really matters as much.

To find out more about Debian from MeeGo perspective, please see the recent mailing list post Mobile UXes - From the DebConf11 BoF to the stars where I wrote most of the MeeGo (CE) part when I was asked to and known of my MeeGo involvement.

Last but not certainly least, there is the Mer project - originally "maemo reconstructed", ie. making Nokia's "not really distro" into a real distro by filling in the void places. Now it's obviously MeeGo reconstructed, and they aim to be the MeeGo they always wanted MeeGo to be! Read the post for details from Carsten Munk and other key Mer people. They share the love for Qt, and want the core to be as lean as possible. They also aim to incorporate the most community like aspect from MeeGo - MeeGo CE - as the reference vendor in Mer. They also aim to be Tizen compliant - and when Tizen comes alive, I wouldn't see why the Tizen reference implementation couldn't be used for saving resources. Maybe Nomovok and/or others could offer the Qt maintaining part.

So, it might be that Tizen itself is enough for most people's needs. The key point however in this post is not to fall in agony if one corporate based project takes big turns - it has happened before, it will happen in the future. There are always enough political and business reasons from some points of view to do Big Changes. But the wider community is out there, always, and it's bigger than you think. You should consider where you want to contribute by asking yourself why you are/were part of for example the MeeGo community. Aaron Seigo from KDE asked us all this question in the Openmind MeeGo Reignited session, and I think it's good to repeat.

Read more