Packages

Patches

Conclusion

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

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, &hash);
}

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

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:

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

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.

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

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

• Neo FreeRunner (GTA02a5) running QtMoko
• Neo FreeRunner (GTA02a7) running Debian
• Nokia N900 running MeeGo CE (now Nemo Mobile)
• Nokia N950 running Meego CE (now Nemo Mobile)
• Nokia N9 running Harmattan (stock software)

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:

• Software Center roadmap – the feature planning for Software Center in the upcoming release
• App developer community growth – laying out the foundations to build and grow the Ubuntu app developer community
• App developer resources section update – the plans to update the Information Architecture on the resources section of the app developer site
• App developer support community growth – defining the roadmap for a community to share knowledge and provide support between app developers
• App developer tutorial growth – an initiative to create a rich set of development tutorials on the app developer site
• App Review Board update and planning – the App Review Board roadmap for 12.04
• Quickly 12.04 Enhancements – the plans to make Quickly better and keep pace with the platform
• Qt panel – a Q+A and all-round discussion session about the Qt roadmap and other topics
• Qt integration – a session on how to integrate Qt to Ubuntu development tools and APIs
• QtQuick workshop for designers – a showcase of the tools QtQuick makes available to designers to integrate their output in the development workflow

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

See you all there!

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.

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:

• Day 1 Summary
• Day 2 Summary
• Day 3 Summary
• Day 4 Summary
• Day 5 Summary (this post)

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!

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:

• Day 1 Summary
• Day 2 Summary
• Day 3 Summary
• Day 4 Summary

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!

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!

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 Quickly – Michael 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 Process – Allison 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 Apps – Ted 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 translated – Henning 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!

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:

• http://lists.trolltech.com/qt-interest/2007-02/thread00694-0.html
• http://stackoverflow.com/questions/2206737/pyqt-jpeg-support-not-working-in-bundled-form
• http://www.thetoryparty.com/wp/2009/03/03/pyqt4-i-hate-you/

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.

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.

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

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

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

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

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

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

All rights reserved © Marcin Juszkiewicz
Is this the end of Maemo5? was originally posted on Marcin Juszkiewicz website

Share/Bookmark

Related posts:

1. Going to Android
2. MeeGo">Maemo -> MeeGo
3. System updates repository for Maemo5?

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

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

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

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

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

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

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

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

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

Rest of functionality was moved to menu and separate window:

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

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

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

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

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

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

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

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

All rights reserved © Marcin Juszkiewicz
Is designing UI simple with Qt? was originally posted on Marcin Juszkiewicz website

Share/Bookmark

Related posts:

1. Switched from Catorise to ApMeFo
2. N900 — second day
3. Zaurus line officially ended

So far, Apport package hooks were limited to collecting data from the local system. However, a lot of debugging recipes and standard bug triage ping pong involves asking the reporter further questions which need reponses from a human. This can range from a very simple information message box “Now, please plug in the camera which is not detected” until a complex decision tree based on the symptoms the user sees.

As discussed at UDS Barcelona, Apport will grow this functionality in Karmic. A first preview is available in my PPA. The GUI looks horrible, but the API for hooks won’t change any more, so you can now begin to develop your interactive hooks.

Example:

import apport.hookutils

def add_info(report, ui):
    apport.hookutils.attach_alsa(report)

    ui.information('Now playing test sound...')

    report['AplayOut'] = apport.hookutils.command_output(['aplay',
            '/usr/share/sounds/question.wav'])

    response = ui.yesno('Did you hear the sound?')
    if response == None: # user cancelled
        raise StopIteration
    report['SoundAudible'] = str(response)

Please see the package-hooks.txt documentation for details.

I implemented all currently existing UI functions (information, yes/no question, file selector, multiple choice dialog) for GTK and CLI, and all except the multiple choice dialog for Qt. Anyone willing to hack on an implementation of ui_question_choice() similar to what the GTK frontend is doing?

Update:I merged Richard Johnson’s branch (thanks!) and uploaded a new package into my PPA. apport-qt is now fully functional.