Canonical Voices

Posts tagged with 'qt'

mandel

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:

123
124
125
126
127
128
129
130
131
132
 
    // NOTE: using SIGNAL/SLOT macros here because new-style
    // connections are flaky on ARM.
    c = connect(impl->systemDownloadManager.data(), 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

Sudoku
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
mandel

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:

1
2
3
4
5
6
7
8
9
10
11
void
TestBaseDownload::testStartQueued() {
    QScopedPointer<MockDownload> down(
        new MockDownload(_id, _path, _isConfined, _rootPath, _url,
            _metadata, _headers));
    down->start();
    EXPECT_CALL(*down.data(), startDownload())
            .Times(0);
 
    QVERIFY(Mock::VerifyAndClearExpectations(down.data()));
}

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

1
QVERIFY(Mock::VerifyAndClearExpectations(down.data()));

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(down.data())' returned FALSE. ()
   Loc: [/home/mandel/Canonical/udm/upload-interface/ubuntu-download-manager-tests/test_base_download.cpp(139)]

Read more
mandel

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
mandel

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:

1
2
3
4
 
connect(_reply, static_cast<void(QNetworkReply::*)
    (QNetworkReply::NetworkError)>(&QNetworkReply::error),
        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
mandel

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:

Download

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

Packages

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.

Patches

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.

Conclusion

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 X.org 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 X.org 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 X.org 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 X.org, 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
mandel

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
#ifndef DBUS_HELPER_H
#define DBUS_HELPER_H
 
#include 
#include 
#include 
#include 
 
typedef QHash DBusStringHash;
class DBusHelper : public QObject
{
    Q_OBJECT
public:
    static int DBUS_STRING_MAP_ID;
 
    explicit DBusHelper(QObject *parent = 0);
 
    static class _init
    {
        public:
            _init()
            {
                // diff actions to init
                qRegisterMetaType("DBusStringHash");
                qDBusRegisterMetaType();
                DBUS_STRING_MAP_ID = QMetaType::type("DBusStringHash");
            }
    } _initializer;
 
    static QVariant getVariant(DBusStringHash hash);
 
};
 
Q_DECLARE_METATYPE(DBusStringHash)
#endif // DBUS_HELPER_H
1
2
3
4
5
6
7
8
9
10
11
12
13
// required for the init
int DBusHelper::DBUS_STRING_MAP_ID = 0;
DBusHelper::_init DBusHelper::_initializer;
 
DBusHelper::DBusHelper(QObject *parent) :
    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
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
gerryboland

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! :)

To show it off, here is a screengrab of the Testability Visualizer application which allows you to connect to a running application, dig into the QObject tree and investigate what’s going on (here, the Unity 2D Launcher – it will be good to zoom in):

Image

On the left is an interactive snapshot of the UI, in the centre is the QObject tree which you can navigate, and on the right is the list of the selected QObject’s properties, methods and signals you can interact with.

On display in that screengrab are some of the attributes of the QDeclarativeImage object which draws the Terminal icon in the launcher (this is defined in QML!) – you can read off the source of the image, the x,y coordinates, width & height, and a whole lot more.

All these properties, methods, signals, etc, are scriptable via Ruby. Thus we can emulate every interaction that a user can make with the application, and determine the reaction matches our expectation.

And all this power comes with almost no changes* to the source code! (* = just need to add object names, see later)

This forms the foundation for the Unity 2D User Experience testing suite.

How Testability Works

First some definitions:
“target” = the machine with the software being tested
“host” = the machine running the test suite, and controlling the target

Testability works as follows

  • any Qt application using Qt4.6+ can be tested by executing it with the “-testability” switch.
  • a standalone server “qttasserver” runs in the background.
  • With the -testability switch, the Qt library tries to load a “libtestability.so” plugin which establishes a connection between the application and qttasserver, giving qttasserver access to the root node of the QObject tree.
  • qttasserver then climbs the QObject tree, reads all the info it can and converts it to an XML format. It also can receive commands and cause the application to react upon them (click here, type, etc..).
  • A series of Ruby scripts connect to qttasserver, receive and parse this XML and allow us to script tests and interactions with the application.

Image

Note that there is a clear divide between the machine of the target and of the host.

This means Testability is great for testing software on embedded devices too. (Indeed Meego has been using it for that exact task!). It also reduces the risk that packages used to run the test suite could interfere with the software being tested.

However there’s nothing stopping you having the target and host the same machine.

[The Unity 2D test framework also includes an extra helper library to control the X server, to control the mouse and keyboard, and to manipulate windows on the desktop. As far as X is concerned, a human is controlling it.]

With the ability to fake any form of user input, and directly read the output from the shell applications
themselves, we can test almost every behaviour of the desktop shell. And as a result, the quality of the user’s experience will only go up.

How to get Testability and start writing tests

Unfortunately Testability is not available in Ubuntu’s repositories just yet, but I have it packaged in a PPA. Installation takes a few steps, so I suggest that interested people consult this wiki page.

Tests are just Ruby scripts, so running tests is just a matter of running a Ruby script!

I think it easiest to show how to use Testability with an example:

# Example test for Unity 2D with Testability Driver.
#
# Note: this probably won't succeed on your installation. Only works
# on unity-2d trunk *right now*, something that will change soon.# This is only a taster!require 'tdriver'
include TDriverVerify

# Establish connection to 'qttasserver' on target
@sut = TDriver.connect_sut(:Id => 'sut_qt')

# Execute the application to test, supplying '-testability' flag
@app = @sut.run( :name => 'unity-2d-launcher',
                 :arguments => '-testability' )
# ------------- Start of Testing Code ----------------

# Check Launcher is 65 pixels wide
verify_true(1, 'Launcher is not 65 pixels wide') {
  @app.LauncherView()['width'] == '65'
}

# Check that Terminal tile is using correct icon source
verify_true(1, 'Terminal icon in Launcher is wrong') {
  @app.LauncherList( :name => 'main' ) \
      .QDeclarativeItem( :name => 'Terminal' ) \
      .QDeclarativeImage( :name => 'icon' )['source']     == 'image://icons/utilities-terminal'
}
# this is a bad test, as the name "Terminal" can be # localised, meaning a fail if you're using a non-English # installation. Choosing good objectNames is important!

# ------------------- Clean up -----------------------
# This closes (kills actually) the launcher when we're done.
@app.kill

There is some boiler-plate code there, but the bits I want to point out are:

@app.LauncherView()['width']

This causes Testability to search for an object of type “LauncherView()” in the QObject tree, and if found reads its “width” property and returns it. Then in Ruby, we can check this value matches what we expect (65).

The second test does a similar operation, but needs a little more help. As there are many tiles, we need to help Testability to find the exact tile we want. We do this by adding some object names (“main”, “Terminal”) to the C++/QML.

By consulting with the Visualizer image above, maybe you can see how Testability navigates the tree to find the icon source for the Terminal tile!

Once you can track down objects uniquely, you can then start interacting with them, send mouse clicks, set properties, call methods, etc. This power gives you great flexibility in testing your application!

Demo

As a demo, here is a video of a part of the Unity 2D test suite in action. On the right is Ubuntu Oneiric running inside VirtualBox, where the Launcher will be tested. On the left is my host machine terminal running the test suite.

Various hide/show tests are being performed, with windows in the way, mouse being controlled, keyboard shortcuts being pressed etc.

Our policy is that every new feature and bug fix in Unity 2D will now be tested like this. You can see our growing test suite here. This will ensure Unity 2D remains reliable, consistent and fast. Thanks to Testability!

Tests will improve your project’s quality too. Will you give it a try?

- Gerry Boland


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 freedesktop.org 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
David

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
David

Another edition of the Ubuntu App Developer Week and another amazing knowledge sharing fest around everything related to application development in Ubuntu. Brought to you by a range of the best experts in the field, here’s just a sample of the topics they talked about: App Developer Strategy, Bazaar, Bazaar Explorer, Launchpad, Python, Internationalization, Launchpad Translations, Unity, Unity 2D, Gedit Developer Plugins, the MyApps Portal, the App Review Board, the UbuntuSoftware Centre, Unity Mail, Launchpad Daily Builds, Ubuntu One APIs, Rapid App Development, Quickly, GooCanvas, PyGame, Unity Launcher, Vala, the App Developer Site, Indicators, Python Desktop Integration, Libgrip, Multitouch, Unity Lenses, Ubuntu One Files Integration, The Business Side of Apps, Go, Qt Quick… and more. Oh my!

And a pick of what they had to say:

We believe that to get Ubuntu from 20 million to 200 million users, we need more and better apps on Ubuntu
Jonathan Lange on making Ubuntu a target for app developers

Bazaar is the world’s finest revision control system
Jonathan Riddell on Bazaar

So you’ve got your stuff, wherever you are, whichever device you’re on
Stuart Langridge on Ubuntu One

Oneiric’s EOG and Evince will be gesture-enabled out of the box
Jussi Pakkanen on multitouch in Ubuntu 11.10

I control the upper right corner of your screen ;-)
Ted Gould on Indicators

If you happened to miss any of the sessions, you’ll find the logs for all of them on the Ubuntu App Developer Week page, and the summaries for each day on the links below:

Ubuntu App Developer Week – Day 5 Summary

The last day came with a surprise: an extra session for all of those who wanted to know more about Qt Quick and QML. Here are the summaries:

Getting A Grip on Your Apps: Multitouch on GTK apps using Libgrip

By Jussi Pakkanen

In his session, Jussi talked about one of the most interesting technologies where Ubuntu is leading the way in the open source world: multitouch. Walking the audience through the Grip Tutorial, he described how to add gesture support to existing applications based on GTK+ 3. He chose to focus on the higher layer of the uTouch stack, where he explained the concepts on which libgrip, the gesture library, is built upon, such as device types and subscriptions. After having explored in detail the code examples, he then revealed that in Oneiric Eye Of GNOME and Evince, Ubuntu’s default image viewer and default PDF reader, will be gesture-enabled.

Check out the session log.

Creating a Google Docs Lens

By Neil Patel

Neil introduced his session explaining the background behind Lenses: a re-architecture effort of the now superseded Places concept to make them more powerful, provide more features and make it easier to add features through a re-engineered API. Lenses create its own instance, add categories, filters and leave the searching to Scopes. The Lenses/Scopes pairs are purely requests for data, independent of the type of UI, and being provided by the libunity library, they can be written in any of the programming languages supported by GObject Introspection (Python, Javascript, C/C++, Vala, etc.). To illustrate all of this concepts, Neil devoted the rest of the session to a real example of creating a Lens for Google Docs.

Check out the session log.

Practical Ubuntu One Files Integration

By Michael Terry

Another hands-on session from Michael, with a real world example on how to supercharge apps with cloud support. Using his experience in integrating the Ubuntu One Files API to Deja Dup, the default backup application in Ubuntu, he went in detail through the code of a simple program to talk to a user’s personal Ubuntu One file storage area. We liked Michael’s session so much that it will very soon be featured as a tutorial on developer.ubuntu.com!

Check out the session log and Michael’s awesome notes.

Publishing Your Apps in the Software Center: The Business Side

By John Pugh

Ubuntu directly benefits from Canonical becoming a sustainable business to support its development, and that’s exactly what John talked about. Being responsible for business development in the Ubuntu Software Centre, he’s got a privileged  insight on how to make it happen. He started off explaining that the main goal is to present Ubuntu users with a large catalog of apps available for purchase, and then continued concentrating on how to submit paid applications to be published in the Software Centre. A simple 5-step process, the behind-the-scenes work can be summarized in: Canonical helps packaging the app, it hosts the app and provides the payment via pay.ubuntu.com, in a 80%/20% split. Other highlights include the facts that only non-DRM, non-licensed apps cannot be submitted right now, but there is ongoing work to implement license key support, and that MyApps, the online app submission portal, can take any nearly any content: apps with adverts, “free” online game clients and HTML5 apps.

Check out the session log.

Writing an App with Go

By Gustavo Niemeyer

Gustavo’s enthusiasm for Go, the new programming language created by Google shows every time you start a conversation with him on that topic. And it showed as well on this session, in which he created yet another “Hello world” application in a new language -you guessed-: Go. Along the way, he had time to describe all of the features of this new addition of the extensive family of programming languages: statically compiled with good reflection capabilities, structural typing, interfaces and more.

Check out the session log.

Qt Quick At A Pace

By Donald Carr

Closing the week on the last -and surprise- session, we had the luxury of having Donald, from the Nokia Qt team, the makers of Qt itself, to talk about Qt Quick. Using a clear and concise definition, Qt Quick is an umbrella term used to refer to QML and its associated tooling; QML being a declarative markup language with tight bindings to Javascript. A technology equally suited to mobile or to the desktop, QML enables developers to rapidly create animation-rich, pixmap-oriented UIs. Through the qtmediahub and Qt tutorial examples, he explored QML’s capabilities and offered good practices for succesfully developing QML-based projects.

Check out the session log.

Wrapping Up

Finally, if you’ve got any feedback on UADW, on how to make it better, things you enjoyed or things you believe should be improved, your comments will be very appreciated and useful to tailor this event to your needs.

Thanks a lot for participating. I hope you enjoyed it  as much as I did, and see you again in 6 months time for another week full with app development goodness!


Read more
David

App Developer Week

What an awesome week for application developers. Ubuntu App Developer Week was a week of great speakers, great sessions, great participation, Multitouch, Unity, GObject, Introspection, PyGI, Qt, Qt Quick, QML, Internationalization, KDE, Phonon, Multimedia, Touchegg, Plasma Widgets, Python, Testing, Rapid Prototyping, Thunderbird, GStreamer, Zeitgeist, D-Bus, Ubuntu One, Bazaar, Lenses, Launcher API, Indicators, Launchpad, Translations, Application Review Process, Packaging, pkgme, the Sound Menu, and much much more.

Here’s a recap of the whole week:

If you happened to miss any of the sessions, simply head to the Ubuntu App Developer Week page where you’ll find the logs for all of them.

Ubuntu App Developer Week – Day 5 Summary

Here comes the last of the summaries for your reading pleasure. Enjoy!

Qt Quick: Extend with C++

By Jürgen Bocklage-Ryannel

In this session Jürgen did another brief intro to Qt Quick: a declarative language to creat user interfaces on top of Qt C++. The subject was to extend it using the C++ language, and for this he introduced QtDeclarative, a UI runtime provided in a Qt module Qt Quick is based on. After this, he walked us through code examples: the first step – include QtDeclarative in the project in order to be able to use it in a C++ main.cpp file. Starting with basic tasks such as changing properties such as the colour of a rectangle from the C++ side, he went into more advanced ones, such as create a new qm element. Even more advanced tasks, such ad creating own elements, were left as a reading exercise with a pointer to the exhaustive Qt Quick documentation and tutorials.

Check out the session log here.

Phonon: Multimedia in Qt

By Harald Sitter

For the third time this week, Harald rocked the house with an entertaining and enlightening session: Phonon, a multimedia abstraction library. First, he showed how to get the environment set up and tools installed; next: an intro to Phonon – an abstraction layer between multimedia apps and a multimedia library backend in the form of a plugin. And next up some coding: the famous 3-line example to create a Phonon-based video player with C++. He showed us how to write a simple audio player, to which then video was progressively added. As a finale he pointed to a way to create a video player with no code at all!

Check out the session log here.

Integrating music applications with the Sound Menu

By Conor Curran

Conor started off explaining that sound menu integration in the next cycle will be made much easier through libunity, and talked a bit about the sound menu spec and the resources for contributors. He then explained that this cycle he concentrated on settling the architecture, making it easier for clients to provide integration. The only thing for a client to care about is to raise an MPRIS interface with a desktop entry, which will then allow it to be shown in the sound menu, and if available, any D-Bus menu items with it. He wrapped up with a description of some of the new features this cycle and an outlook on the next.

Check out the session log here.

pkgme: Automating The Packaging Of Your Project

By James Westby

On to packaging: James introduced pkgme, an almost magic tool to package your application to be distributed to users. Assuming your project uses a standard layout and pkgme has heard of it, it will use one of its backend to create the packaging structure tailored to your layout and toolset. New backends can be created upon request. As the finale, a recursive example: he showed us how to use pkgme to package pkgme itself!

Check out the session log here.

Unity Technical Q&A

By Jason Smith and Jorge Castro

Jason and Jorge started off this exciting session with an introduction to the cool things you can do in Unity: Lenses – bits of pluggable UI to mash up websites and applications in the dash, the Launcher API. After that questions started to kick in: What’s dee? Can you add multiple progress bars to the launcher? What’s the status of progress bars, badges and counters in the launcher? What search backend does the dash use? … if want to know the answer to these and more questions check out the session log :)

Check out the session log here.

Lightning Talks

By Stefano Palazzo, David Callé, Dustin Kirkland, MeanEye, Christian Muehlhaeuser, Nathan Handler

As the grand finale for a week packed with great sessions, even more concentraded content on a set of lightning talks to showcase cool projects created using the technologies available in Ubuntu: StackExchange App – a Unity Lens designed to work with Ask Ubuntu; Unity Book Lens – a Unity Lens to search through free online libraries; Bikeshed – a breeding ground for new/interesting/even-trivial-but-helpful scripts and programs; Sunflower FM – a twin-panel file GTK+ manager; Tomahawk – a social music player written in C++ and Qt; ClassBot – an IRC bot to help with running classroom sessions in #ubuntu-classroom

Check out the session log here.

Thanks!

I’d like to thank all session leaders for taking the time to prepare awesome content and deliver the sessions, and all participants for their attention and their interesting questions. You all made Ubuntu App Developer Week possible, and a success!

We’ll be back in 6 months time with a newer and cooler App Developer Week edition for you. See you then!




Read more
David

Ubuntu App Developer Week – Day 4 Summary

Ramping up to the end of the week we had another full app development goodness day, and one where the session topics fitted together in a nice workflow as well: creating bling, creating apps with Rapid Prototyping, getting them into Ubuntu, adding indicator support and translating them. Here’s the report of yesterday’s app development journey:

Qt Quick: Elements/Animations/States

By Jürgen Bocklage-Ryannel

The next Qt Quick session was all about creating attractive and usable user interfaces. Jürgen went through the QML tutorial documentation and code examples, showing us how to position elements with anchors, columns, rows and grids. Then onto states and transitions: describing the changes in an element’s properties and how to switch between them. To finalize, the most impressive stuff: QML animations, in which he teached us the different types of animations and how to use them.

Check out the session log here.

Qt Quick: Rapid Prototyping

By Jürgen Bocklage-Ryannel

In Jürgen’s words, Qt Quick was designed to bridge the gap between designers and developers, letting both groups to work with the same technologies and code base. He explained how Qt Creator provides a design mode which allows easy dragging and dropping of UI elements, and separation between code and interface. All through a natural and agile prototyping workflow.

Check out the session log here.

Rapid App Development with Quickly

By Michael Terry

Michael started introducing what Quickly at the heart is: a robust yet simple system of templates with boilerplate code and commands. The available templates are ubuntu-application, ubuntu-cli, ubuntu-pygame and ubuntu-flash-game, and on the Natty version, Quickly will feature the ‘submitubuntu’ command to help getting applications into the Software Center. All that being set straight, he then showed how to use Quickly and what it can do: from creating the first example application, to modifying the UI with ‘quickly design’ and Glade, into debugging and finally packaging.

Check out the session log here.

Getting Your App in the Distro: the Application Review Process

By Allison Randal

Linking from the previous session on how to create an app, Allison explained in a very clear way how to get your applications into Ubuntu, so that they make their way into the OS in a matter of weeks instead of having to wait until the next release. The first step is to submit a ticket to the App Review Board, giving them the essential details for the proposal. They’ll then do the initial review, in which one of the reviewers will volunteer to walk you through the process and help you with suggestions or improvements, to bring the app to a state ready for the final review. There the board will vote in a meeting for the inclusion of the application. After the process description she answered the questions from the audience and wrapped up with some useful tips to application submitters.

Check out the session log here.

Adding Indicator Support to your Apps

By Ted Gould

Ted kicked off with an explanation of what indicators are and their intended use: they should not be used just because they are available – rather as a feature for long running applications, those that are more services to users, to expose that functionality. The next step was to describe how to create indicators through libappindicator, with any language supported by GObject Introspection, such as Python or Javascript, and how to add more features to a basic indicator: accessible labels and attention state. After that he described fallbacks, and how platforms not using Unity can nevertheless use indicators. The final minutes were dedicated to the future of indicators, that for now will focus on API cleanup and stabilization, and introspection improvements.

Check out the session log here.

Using Launchpad to get your application translated -

By Henning Eggers

As a follow up to the talk on how to add native language support to your applications on Monday, Henning described the next step: how to make them translatable in Launchpad and grow a translation community around them. In the first part he showed how to set up a demo project using Launchpad’s staging server, and shared some recommendations on how to make sure the application is correctly set up for translations, followed by an overview on some Gettext concepts Launchpad relies upon. From there, it was straight into business: setting up a translatable project in Launchpad, getting translatable templates imported and exposed to translators, creating a translation community for your project and the workflow for translation. A very detailed overview to get your application to talk any language.

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 5

The last day and the quality and variety of the sessions is still going strong. Check out the great content we’ve prepared for you today:

16:00 UTC
Qt Quick: Extend with C++ – Jürgen Bocklage-Ryannel
Sometimes you would like to extend Qt Quick with your own native extension. Jürgen will show you some ways how to do it.

17:00 UTC
Phonon: Multimedia in Qt - Harald Sitter
Harald, as the lead developer of the Qt/KDE multimedia library Phoon will tell you about the awesomeness that Phonon provides and how it achieves ultimate portability, so that it can even run on vending machines. He’ll also tell you hos to create a video player with 3 lines of code (or in 30 seconds without any code) and much more.

18:00 UTC
Integrating music applications with the Sound Menu - Conor Curran
So you’ve seen the slick sound menu in Ubuntu, and you’re developing a multimedia application, right? You’re then wondering how to seamlessly integrate it into Ubuntu and use all the nice features from the menu as well? Wonder no more, for Conor is the man behind the sound menu and he’ll be delighted to teach you how.

19:00 UTC
pkgme: Automating The Packaging Of Your Project - James Westby
Once you’ve developed a cool application you’ll want to package it and distribute it to users so that they can easily install it in their favourite platform. James will show you how this can be both easy and fun letting pkgme do all the work for you.

20:00 UTC
Unity Technical Q&A - Jason Smith and Jorge Castro
You’ve heard about Unity, the new UI concept which is going to improve several orders of magnitude how you interact with your computer in Ubuntu. You are probably using it already, and you’ll surely have questions and will want to learn more about the coolness it brings. Jason Smith, from the Unity development team, and Jorge Castro, from the Community team know all about Unity and they’ll be here to chat with you.

21:00 UTC
Lightning Talks - Nigel Babu
As the final treat to close the week, Nigel has organized a series of lightning talks to showcase a medley of cool applications: CLI Companion, Unity Book Lens, Bikeshed, circleoffriends, Algorithm School, Sunflower FM, Tomahawk Player, Classbot – your app could be in this list next time, do check them out!

Looking forward to seeing you all there!


Read more
David

Ubuntu App Developer Week – Day 3 Summary

Right into the middle of the week and still delivering the most diverse set of sessions from the most interesting technologies. QML, Cloud, D-Bus, Multitouch, Unity, Bazaar… Wednesday had a bit of everything. Most importantly, this sessions are for you all, so I was really glad to hear feedback on how people liked the content of App Developer Week! So here’s a new summary for all of those who couldn’t attend.

Qt Quick: QML the Language

By Jürgen Bocklage-Ryannel

In his first session, Jürgen gave a short intro to Qt Quick’s QML language and how to use it. The first steps were to install Qt and Qt Creator, followed by a description of what Qt Quick is and how developers came up with a declarative way, similar to CSS or JSON to write in the language. All that clear, he then started with the Qt Quick tutorial and code examples that could be run with qmlviewer, the qml interpreter. Onto the second part, he focused on the QML languate, and going into the detail on how to create custom QML components. There were also lots of pointers to the excellent Qt documentation.

Check out the session log here.

Make your applications work in the cloud with Ubuntu One

By Stuart Langridge

Stuart gave a great overview on how to add the cloud to existing apps and how to make new apps for the cloud, letting Ubuntu One do all the hard work for you: from managing identities, password renewal to sharing data between applications. And all that on the web, the desktop, mobile… all your stuff everywhere! He then showed us some simple code to sync playlists on the cloud, ready for streaming. File sync is also an important Ubuntu One feature apps can make use of for sharing, and he also went through a couple of the many cool ways you can use it. The last mention was on API documentation, something Stuart is working on in this cycle.

Check out the session log here.

Take control of your desktop easily with DBus

By Alejandro J. Cura

In this session Alejandro showed us in a hands-on and easy to follow way different bits and pieces of D-Bus, and how applications in the desktop can communicate through it. He went through real life examples to show how to do simple tasks and explained how they can be achieved with D-Bus.

Check out the session log here.

Touchégg: Bringing Multitouch Gestures to your Desktop

In the second multitouch session of the week, app developer José Expósito started showcasing Touchégg, how it works and its features: recognizing multitouch gestures and getting the most of multitouch devices. He then went on describing which gestures it supports, such as tap, drag, pinch or tap & hold, and the different actions that can be associated to gestures, showing us a really cool video of Touchégg in action. The second part of the talk focused on describing the technologies used to develop Touchégg: uTouch-GEIS, through its simplified interface, and Qt.

By José Expósito

Check out the session log here.

Unity: Integrating with Launcher and Places

By Mikkel Kamstrup Erlandsen

Mikkel used the intro of the talk to set a couple of things straight: “Places” are going to be called “Lenses” in the next cycle, and libunity does not yet guarantee API or ABI stability. He then followed with the Unity Launcher integration, and how applications can use static quicklists, and more advanced features such as count, progress bar, window flashing and dynamic quicklists. The second part were Places: remote databases that provide data for Unity to render. Through a Python code example he showed us in detail all the aspects of creating a Unity Place.

Check out the session log here.

Tracking Source Code History with Bazaar

By Jelmer Vernooij

Jelmer, in his experience of seasoned Bazaar hacker started off introducing what bzr is: a modern distributed version control system. He then went on with the basics with a hands-on example, going through the creation of a branch, the first commit, and describing several of the most handy bzr commands. As a wrap-up, he showcased more advanced features such as source recipes: scripts that combine branches and build daily Debian packages from them.

Check out the session log here.

The Day Ahead: Upcoming Sessions for Day 4

We’re featuring a Qt Quick Marathon today: 2 sessions in a row. Following that, how to do RAD with yet another framework: Quickly, how to get your applications in Ubuntu, and how to get them translated in Launchpad. Enjoy!

16:00 UTC
Qt Quick: Elements/Animations/States – Jürgen Bocklage-Ryannel
Another day and more featured Qt content: this time Jürgen will take us through different elements/animations and states Qt Quick provides, and will show us through examples how to make use of them.

17:00 UTC
Qt Quick: Rapid Prototyping – Jürgen Bocklage-Ryannel
If one session weren’t enough, here’s the continuation: more Qt goodness, this time a hands-on session to develop a small application from start to finish and experience the whole process from the front row.

18:00 UTC
Rapid App Development with QuicklyMichael Terry
Mike will show you how to write applications in no time with the power of Python and Quickly: bringing back the fun in programming.

19:00 UTC
Getting Your App in the Distro: the Application Review ProcessAllison Randal
A while back we created an easy process defining how to get applications into Ubuntu, so in order to be able to add them in a matter of weeks, rather than waiting for the next release. Allison, in her Ubuntu Technical Architect and Application Review Board member hat, will walk you through the Application Review Process

20:00 UTC
Adding Indicator Support to your AppsTed Gould
Join the man who knows most about indicators in a session that will teach you how to integrate your application even more into Ubuntu. They’re slick, robust and consistent: bringing indicator support to your apps.

21:00 UTC
Using Launchpad to get your application translatedHenning Eggers
One of the coolest features of Launchpad is that it helps growing a translation community around your project. You can make your application translatable in Launchpad and be able to deliver it into almost any language. Henning will teach you how to do this, picking up where the previous session on translations left.

Looking forward to seeing you all there!


Read more
mandel

So far using py2exe has not been walk in the park with several issues so far and this time it could not be different…. The interesting issue brought to me by py2exe this time was during the runtime of a pyqt application in which the following was being print to stderr:

QObject::moveToThread: Current thread (0x21a3410) is not the object's thread (0x19af0d0).

Funny enough that error would not happen if the application was not froze (WTF!). After some help from ralsina and some googling we found the following:

In my case I was pretty scared that the actual issue was related to the that the operation of the QObject was taking place in a twisted deferred callback and that qtreactor might be doing something naughty. At the end it turned out that the issue was related to the use of a jpg image which requires to use an image plugin in Qt… I fixed the issue as per this. Nevertheless I have made the required changes so that such a hack is hidden in the Windows code and that the Qt UI can be used in Kubuntu without dirty code so if everything goes as planned, SSO should have a buggy t UI that runs on Kubuntu.

Read more
mandel

The following bug I have been faced with has made me loose more time that I would have expected and therefore I think is a good idea to describe it so that the rest of the internet can take advantage of my wasted time and also to keep a record of my stupidity.

After building the .exe file of the ubuntu-sso port to windows I was getting the following error at runtime:

Cannot mix incompatible Qt library (version 0x40701) with this library (version 0x40702)

Usually this means that you have two different version of Qt installed are you are mixing the libraries (.dll in this case because I was dealing with Windows). My initial reaction was to look at my Qt setup in the machine and compared the version installed in the system and that used by PyQt. Let me tell you that is a waste of time. The real reason behind this runtime error was the fact that I was using the qtreactor and I had PyQt and PySide installed in my system.

When not freezing the application, the fact that you have both packages installed is not a problem what so ever, but with py2exe it is. Py2exe bundles all the dependencies you app has and due to the fact hat qtreactor does the following:

try:
    from PyQt4.QtCore import QSocketNotifier, QObject, SIGNAL, QTimer, QCoreApplication
    from PyQt4.QtCore import QEventLoop
except ImportError:
    from PySide.QtCore import QSocketNotifier, QObject, SIGNAL, QTimer, QCoreApplication
    from PySide.QtCore import QEventLoop

both, PySide and PyQt were included in the frozen app. The problem arises due to this fact. When py2exe adds both libs, it copies the Qt dlls you depend on, and if PySide and PYQt depend on different versions (which is what was happening in my system) you might run into the issue of getting dlls from different versions because py2exe will override the already copied dlls without telling you.

In summary if you get the above runtime error, take a look to see if PySide and PyQt have ben included in your frozen app and if they depend in different versions of Qt.

Read more