Online Glom’s standard UI strings are now translated too, instead of just the strings that are in the .glom files. I added some initial translation files (mentioned here too) but I need people to translate them, please. Feel free to just email the file to me. I am tempted to add them to the desktop UI’s translations so I can copy them across.

I also changed it from using a lang= token in the URL to using GWT’s regular locale= query value, re-simplifying much of my previous Online Glom code to support translations.

Now that I see how each new translation adds another set of gwt-java-to-javascript permutations to the already-slow build, so it now builds 41 permutations, I might switch later from the Constants to the Messages technique for GWT translation, because I don’t think that string lookup will be a big performance problem.

In General

I know I have been quite silent about Rygel in general lately because I was quite busy with my day job. Since Zeeshan left Nokia after the MeeGo turmoil I took over his task of bringing Rygel in good shape to form the basis for Harmattan’s DLNA functionality.

These efforts, started long ago by Zeeshan, are finally coming to a close and entering the wild. With the release of PR1.2 beta for the N950, the alert reader might have spotted the release note entry “Media sharing with DLNA compatible devices”. You can probably guess what that’s powered by

One of the goals that we’d set ourselves has already been reached. The device is UPnP certified. The DLNA compatibility is in really good shape as well.

That is one of the reasons why the upstream Rygel development looks kind of stalled. The other one is that we’ve been focusing on ironing out the rough edges with emphasis on stability. Naturally, all of the patches that resulted here have been upstreamed, either to Rygel, GUPnP or libsoup.

On the device

So what’s on the device? A more or less pristine upstream snapshot taken several commits after 0.11.3 with later patches cherry-picked and some minor adjustments to adapt ourselves to the environment, like different device details and icons.

What can it do?

It implements a M-DMS, a mobile media server, enabling you to share the media content of your phone in your home network.

In addition to the rather useless mandatory media formats defined by DLNA we have decided to include a LPCM transcoder and the necessary profiles to share all the videos and images you’re going to take or already have taken on the device.

The server runs in a strict sharing mode where only media files that conform to one of the supported DLNA profiles are shared. This is configurable and we plan to release a “tweaking app” later to help the average end user to fine-tune and undo some of the limitations that had to be done due to the DLNA guidelines.

So, to all that already can, enjoy Rygel on your mobile phone.

Introduction

The development for Maliit, a cross-platform text input method framework for mobile devices, until 0.8 was mainly based on requirements for MeeGo Harmattan, the operating system on the Nokia N9. Harmattan applications are fullscreen. Animation of orientation changes is, together with other animations, done by the application. This is in contrast to Maemo Fremantle on the Nokia N900, were such animations were done by the X window manager.
When the virtual keyboard is up, the application remains fully interactive. Instead of using a proxy text entry, the text input goes directly to the application’s focused text entry. Showing the virtual keyboard should not change the layout, nor can it affect the application’s stability. The virtual keyboard runs in a separate process (maliit-server). But it requires animations showing, hiding and switching between different language layouts. In addition it should be possible to display overlays for word candidates or extended keys.
To satisfy these requirements the virtual keyboard window is shown in fullscreen mode. The visible parts of the virtual keyboard cover the bottom area of the application and screen, whereas the remaining area of the toplevel window is seemingly translucent. This keeps most of the application visible, including the focused text entry, which will render any text input immediately. It is also possible to pan the application’s page contents and to switch focus to another text entry, or remove focus altogether.

Shaped input region

To pass input events through to the application we use the shape extension of the X server and XFixesSetWindowShapeRegion to set the input shape of the MPassThruWindow to the region which the virtual keyboard and overlays really occupy. The X server will deliver events inside this region to the input method, and the rest to the application window.

void MPassThruWindow::updateInputRegion()
{
	XRectangle * const xrects = convertQRectanglesToXRectangles(region.rects());
	const XserverRegion shapeRegion =
		XFixesCreateRegion(display, rects, region.rects().size());
    	XFixesSetWindowShapeRegion(display, winid, ShapeInput, 0, 0, shapeRegion); 	XFixesDestroyRegion(display, shapeRegion);
	delete[] xrects;
}

Compositing Window Manager

When the window manager supports compositing, it is possible to use 32 bit translucent RGBA windows for the overlay. Mcompositor, Harmattan’s window manager, supports this feature. That is why we turned the background of the top level virtual keyboard window translucent. In Qt this can be done like:

MPassThruWindow::MPassthruWindow()
{
	setAttribute(Qt::WA_TranslucentBackground);
}

Since compositing window managers are widely available for Linux desktops and the performance is acceptable it has been the default for Maliit 0.8.

Direct rendering

When the active application window is fullscreen and the application features a non-translucent background (which is the case on Harmattan), then the redirection of the active window into an off-screen window and additional compositing is unnecessary. Under circumstances, this redirection cuts the frame rate in half, which was unacceptable for animations and scrolling. For that mcompositor supports direct rendering of the active window into the frame buffer.
Since in this mode the keyboard window is transparent mcompositor cannot use the direct rendering optimization. Additional the context switches between the three processes, application, keyboard and compositor results in increased latency for text input, which affects the user experience. To reduce latency we wanted to further optimize performance for Harmattan and the N9 by using direct rendering with a 16 bit window for the keyboard.

Compositing using shaped output region

Our first approach used the same technique for the in- also for the output, with the help of XFixesSetWindowShapeRegion:

void MPassThruWindow::updateInputRegion()
{
	...
    	XFixesSetWindowShapeRegion(display, winid, ShapeBounding, 0, 0, shapeRegion);
	...
}

This solution does not require a compositing window manager but made it difficult to use shadows and overlays. It also was not performing as well as expected, since there is no support for direct rendering of shaped window. A better solution had to be found.

Compositing in Maliit

We were able to try another approach for using direct rendering. A 16bit RGB window together with the composite and damage X extensions is used to compose the content of the application window into the background of the virtual keyboard window. Instead of using the window manager for the compositing, Maliit handles the compositing itself.
The application window is represented through MImRemoteWindow in Maliit. XCompositeNameWindowPixmap is used to get a pixmap of the application’s window content:

void MImRemoteWindow::setupPixmap()
{
	xpixmap = XCompositeNameWindowPixmap(display, winId);
	pixmap = QPixmap::fromX11Pixmap(xpixmap, QPixmap::ExplicitlyShared);
}

This pixmap is blitted into the background of a QGraphicsView:

void GraphicsView::drawBackground(QPainter *painter, const QRectF &rect)
{
        painter->drawPixmap(rect.toRect(), remoteWindow->pixmap(), rect.toRect());
}

To get notified about updates in the application window the damage extension is used:

void MImRemoteWindow::setupDamage()
{
    damage = XDamageCreate(display, winId, XDamageReportNonEmpty); 

}

On damage events there is a signal emitted, which is used to trigger a repaint.

void MImRemoteWindow::handleDamageEvent(XDamageNotifyEvent *e)
{
    XserverRegion parts = XFixesCreateRegion(display, 0, 0);
    XDamageSubtract(display, e->damage, None, parts); 

    QRegion region(convertXRegionToQRegion(parts)); 

    XFixesDestroyRegion(display, parts); 

    Q_EMIT contentUpdated(region);
}

When handing over compositing from the the window manager to the input method process brief flicker can occur. To suppress it, mcompositor had to be patched to only map the virtual keyboard window after the application window has gotten redirected for compositing in Maliit. Additional QWidget attributes need to be set for all QWidgets in the virtual keyboard:

MPassThruWindow::MPassthruWindow()
{
	setAttribute(Qt::WA_OpaquePaintEvent);
	setAttribute(Qt::WA_NoSystemBackground);
}

In addition to improving the performance this approach also allowed to synchronize the rotation animation of the application and keyboard.
This mode is used on Harmattan and the Nokia N9 and can be activated by starting maliit-server with the -use-self-composition flag.

Plugins

Since plugins up until Maliit 0.8 are using fullscreen sized children widgets of the MPassThruWindow, their sizing and positioning depends on the toplevel window being a fullscreen window.
For compositing in Maliit to work, those widgets have to blit the application window content into their background. A QGraphicsView for example can use MAbstractInputMethodHost::background to paint the application window content as its background in QGraphicsView::drawBackground.

Conclusion

The fullscreen keyboard window approach was the proper choice for the Nokia N9 device. But on other devices, where orientation change animations are done by the compositor, or on a desktop system without a compositing window manager a non-fullscreen keyboard window could be a better choice. Unfortunately input method plugins based on Maliit 0.8 releases are tied to the fullscreen keyboard window concept and even need to take care for implementation details like the compositing in Maliit. The Maliit 0.9 series, which provide the basis for a first stable 1.0 release, should be used to find a better solution for plugins which allows different window modes and makes it easier for plugin developers by not burden them with any implementation details.

It took us a while to transform the Maliit project into a real opensource project. At first there was only public code, later some wiki pages @ meego.com together with constantly changing components in the official MeeGo bugtracker, then a public mailing list.

After that we tried to become independent of MeeGo, but neither freedesktop.org nor the GNOME project could give us a suitable home. So we had to go with our own infrastructure in the end, which probably was the best we could do, in any case. We now enjoy our own website (mostly a wiki, for which we can also analyze the traffic), our own IRC channel, our own public bugtracker, our own mailing lists and a build bot. We also make use of other services such as launchpad.org and the openSUSE Build Service, both for packaging but also as part of our continouous integration setup. Both services provide nightly builds for Maliit, for example (though we still lack packages for ARM).

But there was always one thing missing: T-Shirts. Now that this is solved, too, we can finally call Maliit a real opensource project ;-) Hopefully we'll soon have another group photo of the people who've been involved in the project over the years. I'll make sure to bring a couple of T-Shirts to FOSDEM, so make sure grab Jon or me if you want one.

Last week I did a talk about DLNA, what it is and how it relates to UPnP during a DeveloperGarden event hosted in Berlin’s famous hacker space c-base.

A video of the event will be available later but the slides are already available.

Note: Both talk and slides are in German. I will also be giving a short talk about Rygel on this year’s FOSDEM in Brussels.

Building gwt-glom

At least on Ubuntu, it’s now easy to build and test gwt-glom. You can just do:

$ sudo apt-add-repository ppa:openismus-team/openismus-glom-unstable
$ sudo apt-get install default-jdk maven2 libjava-libglom-java glom-utils
$ git clone git://gitorious.org/online-glom/gwt-glom.git
$ cd gwt-glom
$ mvn gwt:run

This opens the GWT Development Mode GUI, which serves gwt-glom via jetty and lets you see it in your browser.

Chrome is the most likely to have the gwt plugin that you need for development mode, though it’s available for some versions of Firefox.

How we made it this easy

GWT projects, like other Java projects, typically use maven (mvn) for their build system. maven is nothing like autotools.

Maven usually downloads dependencies automatically, either from the central maven repository, from some (maybe private) other maven repository that you specify. This sounds unstable, but you specify exact version numbers, so you can be sure that your project will continue to build. So maven doesn’t have the separation of building and packaging that I’m used to in the C/C++/autotools world. It feels odd to me, but I’m going with the flow.

However, java-libglom uses JNI to provide a Java API around a C++ (libglom) API, so it uses both Java (architecture-independent) and C++ (compiled and linked for particular architectures).

java-libglom installs a native shared libary. We packaged that for Ubuntu in our Glom PPA (stable and unstable) as libjava-libglom-java so you can install it easily.

java-libglom also creates .pom and .jar files (for the API, the sources, and the javadoc). These are in the central maven repository so maven can just download the .jar.

That libjava-libglom-java Ubuntu package also installs the .pom and .jar files that maven needs, but those are only useful for mvn-debian, which is apparently only useful for building other Debian/Ubuntu packages. There is no apparently no way to using mvn-debian’s local repository while also using the central maven repository for other stuff.

Java with autotools

By the way, java-libglom uses autotools, although the autotools Java support is barely useful and limiting, so we have custom rules for most stuff. However, autotools does let us generate the Java and C++ files from swig, and build the native shared library. That seemed harder to do with maven, though maven would have made it easier to deal with the generated Java code.

I do like how maven just defaults to using your .java files, and test ,java files properly if you put them in the correct places. For instance, see the maven quickstart project.

This week I changed libglom’s TranslatableItem API to allow Online Glom to use the recent translations of the Glom example files. This requires the latest unstable version of libglom-1.22 and java-libglom.

There is now a language drop-down list at the top-right, and that is shown in the URL as, for instance, &lang=de (I might change that to locale instead of lang). Choosing a different language will change the table titles, field titles, group titles, etc, to the chosen language.

I have deployed that to the Online Glom test server. For instance:

I have not yet done the same for the translatable strings that are in gwt-glom’s Java source code, such as “Search”, and the “Open” and “Details” buttons. I’m not much looking forward to the awkward way that it should apparently be done. gettext’s _() macro is much cleaner.

Meyah and Liam had their birthdays a few days ago – Meyah on the 25th of December and Liam on the 29th.

Meyah is turning out to be just as friendly, energetic and curious as Liam. She’ll be walking soon. This is her second week in the creche, which will be good for her, but feels strange for us.

Liam wants to learn about everything and surprises me every few weeks with his sudden advances. Last week he learned how to play chess though a month before he would not have had the patience.

Raising two kids isn’t easy at times, but it’s the whole point of my life now and nothing has ever made me so happy.

I just implemented my first feature in Online Glom after taking over from Ben Konrath. Luckily I could cargo-cult his work, with some help from Eclipse’s code navigation and refactoring. I added a text box for an easy full text search of the current table, to filter the rows shown. For instance, you can filter the list of packages here.

I’m proud of myself, but I can’t help feeling that it needed far too many code changes, in far too many interconnected classes, just to add a text box in the browser and then use the resulting text to slightly change a method call on the server. I took the time to write a detailed ChangeLog/commit-message just to be sure that I understood what was happening.

This is apparently how things are in the land of Java. In its defence, there are reasons for the abstractions and separations. For instance, OnlineGlom code does the GWT thing of allowing for different View implementations for different clients, such as mobile or desktop, but it only has one type of Views for now. It also uses a Model/View/Presenter architecture, via its Activities, which makes it possible to test more code logic without getting the UI involved. And there’s the Places idea, which maps history tokens (parts of URLs) to Activities and vice-versa.

I wish there were some way to have the useful architecture without the repetitive code that gets in the way of the interesting stuff.

We finally published a video about Maliit - an input method framework including a virtual keyboard - and 3rd party plugins. Kudos goes to Jon for making time for that.

This video highlights one of Maliit's key features: pluggable input methods which come with their very own user interfaces. The Chinese input methods show how Maliit offers support for composed characters. The video is proof that 3rd party development for Maliit (open-source and proprietary) is not only possible but also happening.

maliit.org states that "it should be easy to customize existing input methods or develop powerful new input methods, whether for profit, research or fun", we actually mean it.

The harder question is of course how to motivate others to actually get started on input method development with Maliit. For that, we have a multipronged strategy:

1. Provide sufficiently polished reference plugins that can show off Maliit capabilities but also serve as inspiration for new plugins (hence the BSD license for reference plugins). Our reference plugins are currently using Qt/C++ (Maliit Keyboard) and QML (Nemo Keyboard). We also have PySide support, but no one contributed a reference plugin yet. This gives choice to interested input method developers, and we think that's important. The reference plugins serve another role when it comes to designing new API: They become our testbed, allowing us to verify our API proposals.

2. Ship Maliit with a bunch of example plugins and example applications. None of them try to be complete. They are all self-contained though and usually show one feature at a time. This can be tedious to maintain, but we believe that examples need to stay small and focused, otherwise developers won't look at them.

3. Documentation that is easy to consume. Our documentation is not as concise and clear as we'd like it to be, but it's slowly improving. We also experiment with videos that can serve as an introduction to more in-depth (text) documentation.

4. Packages for most common Linux distributions. This one seems obvious, but sadly, it's quite a lot of work for us to keep up with it (and we already use automated services such as Launchpad and OpenSuse Build Service). In the hope to attract dedicated packagers we wrote down some packaging guidelines

5. An architecture that had 3rd party plugins and multiple toolkit support in mind from the start. The plugin developer facing API needs to be easy to use and clearly documented. This will be the focus of the upcoming 0.9x series.

We will demo Maliit @ FOSDEM 2012, hope to see you there!

Maliit has an architecture where input methods are implemented as plug-ins. This enables a multitude of different input methods to exist and be used in the same way by applications. Maliit comes with a set of reference plug-ins, but there are also third party plug-ins. This video gives a quick introduction to some of them:

Glom‘s files can contain translations for the various table names, fields, relationships, choices, layout groups, reports, etc. This lets multiple people use the same database UI in different languages. Glom doesn’t require programming, so the .glom files don’t use gettext. But Glom can export the translations to .po files so translators can use their familiar tools. This week I added some command line utilities to do that more easily, plus some make rules to use them on the Glom examples.

I can now type “make examples_export_po” to export .po files and “make examples_import_po” to read the improved translations back into the Glom example files.

I put the .po files in Glom’s git repository, hoping that people will translate them, and maybe add more .po files. I wonder if these could even show up on Glom’s l10n.gnome.org page. Update: They do show up there now, thanks to Claude Paroz, and we already have some translations.

Grouping Support

When introducing Dolphin 2.0 I talked about  grouping support for all view modes. But I could not offer any screenshots, as this feature was not ready yet at that time. So here we go showing the same folder grouped by the file type in the icons-mode (which is already available since Dolphin 1.2):


... in the compact-mode:


... and in the details-mode:


I think there is a lot of room for visual improvements of the group-headers especially in the combination with the details-mode. However this is something that needs to be discussed with our Oxygen-gurus Nuno and Hugo and will hopefully be improved in the next version.

Still I'm quite happy with the new implementation. It fixes performance issues that occured with the previous implementation, fixes keyboard-navigation issues and provides a solid base for future extensions like grouping by rating, tags, comments or any arbitrary grouping-category.

General Status

The rewrite of the Dolphin view-engine was a lot of work and resulted in changing of much code. The benefits are an improved performance, getting rid of a lot of bugs that could not be solved with the old view-engine and a better maintainable code-base. But it would be illusionary to expect that there will be only benefits and zero regressions: Dolphin 2.0 will be a typical "dot zero" release where minor issues will popup after the release. However based on the current feedback on bugs.kde.org there seem to be no showstopper bugs left. The currently known regressions and missing Dolphin 1.x features can be seen on the Dolphin 2.0 Status page and I'm confident that during the 4.8.x release cycle most regressions can be fixed.

Outlook for Dolphin 2.1

As the development-focus will be to fix the regressions and making the fixes available for the 4.8.x cycles, there is not much room for big features in Dolphin 2.1. But there is one feature that I miss since Dolphin 1.0 and that could not be implemented with the old view-engine: The showing of any arbitrary meta-data of a file in the views. The tooltips and the information panel already can show things like rating, tags, album-name, image-size and a lot more:


Now in Dolphin 2.1 it will be possible to show all this kind of meta-data as part of a file or directory in all view-modes (this also includes sorting and grouping). The view-engine internally already supports this but I could not finalize the user interface for the 2.0 version.

This makes it e.g. possible to configure a kind of "Music view" where for each song the artist, album-name and the rating is shown. Another usecase might be images, where showing the image-width and -height as part of each image might be useful.

Finally I'd like to say thanks especially to Frank Reininghaus, who helped a lot to get the new view-engine in shape. Frank told me he probably wants to give some development-updates on Planet KDE in future, but I think I need to create some public pressure by mentioning this here to make it happen ;-)

Ben Konrath recently finished up a first real milestone in Online Glom development, and I have deployed it, with the example Glom files, on an Amazon EC2 instance. Online Glom is still a read-only UI, so you can’t edit data in the database, but I think it’s already useful for some situations. Well, I do want to add the quick search feature soon to really finish off the read-only functionality. Report-generation would be good too.

The Film Production Manager example is a fairly good example of the complex systems that Glom can support, without SQL and without programming.

Here’s a screenshot of the same thing in the desktop UI.

I have also deployed my old Debian Repository Analyzer, full of real data, so you can get a feel for navigating around the related records. I spent lots of time updating that for the latest python-apt API and libgda (with python) APIs, and it’s now in a gitorious project. Many thanks to Michael Vogt for his help with python-apt.

Now that David King has packaged java-libglom (as libjava-libglom-java) for Ubuntu Oneiric in the Openismus PPA, it’s really easy to work with the gwt-glom code on that distro.

What’s Next

This proves that GWT was a sane choice, though development has not been as quick as I’d hoped . But I don’t think a generic framework can ever be developed as rapidly as most data-driven web sites that start as quick hacks. The difficulties have shown that I was right to focus on a restricted set of functionality at first. You can get a sense of how development has progressed by looking at the gwt-glom commit log, though there’s lots of work in java-libglom too.

I now plan to take the development further myself. That’s a nice way to get more deeply reacquainted with Java and web development. It’s easier to hack on the project at this stage, before it gets huge, rather than trying to do this from scratch. Ben Konrath has already made the large architectural decisions so that I don’t have to. I’m even enjoying Eclipse, which is a much more pleasant experience with Java than with C++. Well, using the Eclipse IDE is still like shopping in a flea market but with Java you will quickly find useful things.

I plan to do things roughly in this order:

• Add the Quick Find feature, for searching. Update: Done
• Add report generation.
• Add print layout printing.
• Maybe investigate how to make theming via CSS easier.
• Allow editing of data. This will be a big task.

At the same time, I will play with avoiding the need for java-libglom’s JNI binding to the libglom C++ library. I would need to reimplement Glom document parsing in Java, but that would be easy as it’s just XML. But I would also need some replacement for GdaSqlBuilder, to build SQL queries without manually concatenating and escaping text.

 

In Maliit, all changes have to be reviewed by two people in order to be merged to mainline. This helps us catch issues early and keep code quality high. Since the code is hosted on Gitorious, we use their merge requests feature for that purpose. Up until now we have periodically checked the website for changes (potentially going through each and every one of the repositories), and manually mentioned updates in the IRC channel. This is both tedious and inefficient, so I wrote a simple tool to help the issue: Gitorious Merge Request Monitor

It provides an IRC Bot which gives status updates on merge requests in an IRC channel:

16:01 < mrqbot-AfFa1> desertconsulting requested merge of ~desertconsulting/maliit/desertconsultings-maliit-framework with maliit-framework in http://gitorious.org/maliit/maliit-framework/merge_requests/126
16:01 < mrqbot-AfFa1> mikhas updated http://gitorious.org/maliit/maliit-framework/merge_requests/125  State changed from Go ahead and merge to Merged

One can also query the current status from it:

15:02 < jonnor> mrqbot-7ACeB: list
15:02 < mrqbot-7ACeB> maliit-framework/127: - New - Allow QML plugins to add custom import paths for QML files and QML modules
15:02 < mrqbot-7ACeB> maliit-framework/126: - Need info - configurable importPath for qml
15:02 < mrqbot-7ACeB> maliit-plugins/26: - New - Add PluginClose from main view and add key repetition support
15:02 < mrqbot-7ACeB> maliit-plugins/25: - New - Clear active keys and magnifier on keyboard change
15:02 < mrqbot-7ACeB> maliit-plugins/24: - New - Remove QtGui dependency from libmaliit-keyboard
15:02 < mrqbot-7ACeB> maliit-plugins/23: - New - Get rid of Qt keywords
15:02 < mrqbot-7ACeB> maliit-plugins/22: - New - Add phone number and number layout getters.

Status changes are retrieved by periodically checking the Gitorious project activity feed (Atom)*, and the status itself is scraped from the website. There is no other API right now, unfortunately. Implemented in Python with Twisted, feedparser and BeautifulSoup doing all of the heavy lifting.

Get it from PyPi, using easy_install or pip:
pip install gitorious-mrq-monitor
gitorious-mrq-monitor --help # For usage information

For now this solves the immediate need for the development work-flow we have in the Maliit project. Several ideas for extending the tool are mentioned in the TODO. Contributions welcomed!

After having set up the typical things open source projects needs like a website/wiki, mailing-list and bug-tracker, Maliit now also has something not so common: a build-bot.

As Maliit consists of several components that can be built in several different ways (and for several different platforms), we wanted to automate the build and tests of the different variations to ensure that we do not break any of them. This is especially important for variations which are not easy to test for the individual developers, like for instance Maliit on Qt 5.

The software chosen to help with this task was Buildbot. Getting an initial instance it up and running was very quick and pain-free, especially thanks to packages being easily available and the excellent documentation. The current setup now builds, tests and installs the two major components we have: Maliit Framework and Maliit (Reference) Plugins, in the most important build/config variations we have. A total of 12 individual build jobs, plus 2 meta-builds. The configuration for the instance can be found in the maliit-buildbot-configuration repository.

For security reasons the build-bot is not directly exposed to the Internet. Instead a script runs every 5 minutes to generate a static HTML website and publish on the public web-server: Maliit build-bot

This gives us a minimal continuous integration system for Maliit, which for now will hopefully helps us avoid breakage. In the future, the usage of the build-bot might extend to include:

• Automating the release process
• Testing of merge-requests/patches before merging to master
• Automated integration/system testing, complementing the unit-tests
• Triggering external builders for packaging. OpenSUSE OBS, Maemo 5 Garage, etc.
• Automating certain aspects of bug-lifetime. Resolving when fix is committed, closing on release if pre-verified, etc

 

Inspired by someone's lazyweb call I felt like doing something entirely unrelated to my regular work.

libstarred provides a GTK+ cell renderer and a widget for showing and editing five-star ratings.



Feel free to use it. Merge requests welcome. Ideally someone finds time to polish it for inclusion into GTK+ itself.

Btw, hacked using QtCreator's Autotools Plugin.

The Maliit developers and the Plasma Active developers, with some Mer developers too, discussed yesterday how they can work together. Reading the irc log, it seems to have been productive, with great input from all groups, and with some first development steps planned.

As always, I’m proud of our Maliit developers at Openismus. We believe that excellent developers must be communicators, or their work is for nothing. That log shows why.

Qt 5 has a complete new interface for input methods. Instead of the old QInputContext (which is just a wrapper around the new system now) there is now QInputPanel and QPlatformInputContext (no documentation yet, see source), for the reasoning see QTBUG-20088 – Create proper input method abstraction and expose it through a public API in QTGui.

Luckily there is already a simple platform input context for the Maliit input method framework in the Qt code base available. There are some smaller bugs open, but they should be easy to fix. So it should be already possible to use Maliit with Qt 5 applications.

Additionally we would of course like to compile Maliit itself against Qt 5 too. Based on the previous work eliminating the X requirement in Maliit it was a quite easy task to compile it with Qt 5 and required just fixing some smaller bugs and updating some build system files.

After that I tried to run Maliit with the XCB platform. This showed an ugly bug, the virtual keyboard stole the focus from the application. On Qt 4 we used the WA_X11DoNotAcceptFocus Qt::WidgetAttribute which does not work for the XCB (and Xlib) platforms in Qt 5. I filed a bug about this issue and created a patch (which is sadly only visible when one has a gerrit account registered). With that patch applied to Qt 5 Maliit was basically working.

Recently at Openismus I was asked to write a SOAP server, which would run on an OpenWRT router set up by Dave. The server uses libsoup, so writing it was really straightforward, but fun. Of course there were some glitches, like trying to use SoupAddress to set up where server should listen - it ended up in segfaults somewhere inside libsoup. I decided to not use it in the end, but Jens gave me a hint about a function of SoupAddres resolving it first. Segfaults are clearly a sign of bug somewhere in libsoup. Primarily SOAP server had to be someting bigger but for now ended up as an example. There are some things lacking for sure. Like actual compliance to SOAP standard (probably), documentation or subclassing the SoupServer into SoapServer and providing some nice interface hiding all ugly details. But at least it has autotools based build system, client application and some basic tests. So it maybe doesn't look that bad. The code (LGPL 3+) is on Openismus Playground.

I haven’t had the time to blog about the things I wanted to this summer, unfortunately I’m a couple days behind in the project I’m working on now so I’ll have to try to make this brief.

First ever GNOME summit

This took place in Montreal several weeks ago, it’s definitely a late blog post for this but I really wanted express my gratitude.

I did not take any pictures, however I did force some time into my schedule to push out a release of Glade (you could easily say that the latest stable releases of Glade were brought to you in a large part by the GNOME summit).

All in all I just wanted to voice my appreciation for getting the opportunity to shake hands with some of the people I’ve admired over the years, after arguing countless topics with many of the same people on  gtk-devel-list and desktop-devel-list over the last decade, it’s really amazing to get to meet some of these people in real life.

I do wish I had blogged this earlier, and I sincerely apologize for not having been a better host (as Montreal is my home town), it was hard enough to push the summit (and Glade release) into my schedule at all (was more of a great pleasant surprise that the summit actually came to me).

A summer of evolution-data-server

This summer at Openismus we’ve been making some enhancements to the Evolution Data Server as a part of Intel’s effort on the Meego platform.

I haven’t been blogging about this work, generally because I did not feel like there was something to “show off” about, we haven’t invented anything new, however  since yesterday we’ve landed the final patch so I’ll just give a rundown of which patches I was tasked to work on.

Bug 652178: Store PHOTO data as plain files

This is probably the most complex of the patch set, Evolution Data Server’s addressbook api allows storing of image data either as binary encoded blobs or simply as a URI. This patch basically enforces a policy where the local backend of EDS converts any incoming binary data into URIs on disk managed by the addressbook backend.

Bug 652175 and Bug 652177:

These patches add a backend property to the calendar and addressbook, the value of the property is guaranteed to remain the same so long as no data has changed for that backend, whenever data changes in the backend then the overall revision is bumped (this allows tools like SyncEvolution to abort when no data has changed without iterating over the whole database).

Bug 652171 and Bug 652180:

These patches implement an api which already existed but had remained unimplemented. The api allows one to filter the reported results of a calendar or addressbook view to only report some of the desired information (this way if you only want contact names and UIDs for instance, you dont have to transfer full vCards from the EDS just to get them).

All of these patches have landed in Evolution Data Server and should be available in the next (3.4) release.

Here and Now

Only a few days ago I landed back in Seoul, South Korea where I expect to be spending the greater part of the coming year, right now I’m in a guest house and hacking in the basement, it’s a nice quaint little atmosphere that makes you feel like you’re doing some kind of crazy science experiments in grandma’s basement again.

For the next few months I’ll be devoting much of my time to a fun (commercial software) project which is to write the new up and coming Karaoke Application for TouchTunes.

While I can’t directly devote any of the company time to GNOME, I can always find a good excuse to enhance the code at the correct level in the stack instead of working around the problem in an application. It’s always good to prove that it pays off to give back to the community which provides your platform libraries.

 

Well, it’s been great and I hope there are not too many typos … now back to not having enough time to do all the things I must

We kicked off the new 0.81 release series together with a nice announcement: We have our own bugtracker now!

This means that Maliit has a near complete project infrastructure, all available under *.maliit.org, and all that thanks to Karsten, the always professional and very experienced hostmaster here at Openismus.

There is one more thing that we need (as demonstrated by me when I made my first broken release), and that's a simple build bot setup for continuous integration. Right now, we still rely on Nokia's infrastructure. I am confident that buildbot will fit all of our requirements, as long as it is trivial to maintain.

I am also happy that we improved our documentation significantly, thanks to Dave. He translated the important documentation bits into proper English and made it more accessible, demonstrating his doxygen skills. As a bonus, he also updated the project's README files, something we had neglected for a long time.

Future development

Regarding the Maliit development, I think we have simplified things a lot. D-Bus activation for the Maliit server (which finally means one server instance per user session) and the new support for plain QML plugins makes it almost trivial to get started with Maliit. We also let go of the critically acclaimed MeeGo Keyboard in Maliit upstream, which made me a bit sad of course.

Still, it probably was the right decision: MeeGo Keyboard is heavily fine-tuned for Nokia's N9 and it has some dependencies that are hard to satisfy outside of Harmattan. Over time, with ever changing requirements, the code has naturally evolved into a rather complex design. The result, however, is a very polished product, and ultimately, that's the only thing that matters (even though many opensource developers will disagree, strangely enough). Everyone in the team is proud of what we have achieved.

At the same time, I can understand how new contributors will be put off by all the complexity. So Maliit upstream will instead focus on the very basic but almost trivial to build Maliit Keyboard. For new contributors, that's a good thing. For us, it means the possibility to fix shortcomings in the plugin API. This is important, as one of our main goals has always been to enable others to write great input method plugins for Maliit, which will then run on any platform that Maliit supports. The Swype VKB plugin and the Japanese VKB plugin for example both demonstrate that we are on a good way, but I think we can do better.

Maliit itself still needs a good reference plugin, of course, even if only as a showcase (though I want it to be more). All this doesn't mean that MeeGo Keyboard goes away; its development will continue in the MeeGo Touch repositories, just as before (effectively degraded as just another Maliit plugin). But what we can take over, hopefully, is our experience when it comes to creating one of the best virtual keyboards currently available.

Earlier this year I took over maintainership of Gnome System Monitor. It had been neglected for a couple years which was obvious by taking a look at the bugs piling up in Bugzilla. When I started there were about 255 bugs which I quickly got down to just under 200.

Up until a few weeks ago it had stayed at that level. But a few weeks back Robert Roth appeared out of nowhere and started triaging bugs and submitting new patches and updating old patches. He’s been keeping me busy reviewing and applying patches. With his help the bug count is now at 146. Still high but very good progress. So, thanks Robert!

The big new feature so far this cycle is Control Groups support. Jason Baron from Red Hat has added an option to view the control group information for each process. This is a work in progress. I’ve included an early patch in the 3.3.2.1 release. If you find bugs or just want to follow the progress please visit bug #663644. Also, thanks to Lennart for his input on how best to implement this.

With many bugs squashed and a few new features, the 3.4 release stands to be The best release ever (TM).

The Openismus employees who worked on the N9′s Harmattan project received their free Nokia N9 phones from the company yesterday. It was expensive but its the right thing to do.

I released version 3.2.0 of the Programming with gtkmm book, with many corrections and updates from Kjell Ahlstedt and a small chapter about keyboard events from Pedro Ferreira.

As usual, it is available on the Kindle too.

It has taken over a year of hard work but Glom 1.20 is finally ready.

This is the most stable and most usable version of Glom yet, with a few new features, now using gtkmm 3. Here are some updated screenshots. The major changes:

• Simplified main window.
• Glom can now store and display PDFs. It can store any file format, though it can only display images and PDFs.
• Print Layout: Major overhaul with improved UI and new functionality.
• Related Records: Allow the developer to specify how many rows to show.
• Choice drop-downs can show more than 2 fields.
• Choice drop-down fields are aligned.
• Choice drop-downs can show related fields.
• List columns have sensible widths.

Around 20 bugs from bugzilla were fixed, plus several more.There are over 30 tests that prevent regressions in mostly non-UI code. I still wish I could get some kind of automated UI testing working.

We have packaged Glom 1.20 (and several dependencies) for Ubuntu 11.10 (Oneiric) in the Openismus PPA. We might do something similar for Fedora.

Unfortunately, it will probably take a year for Glom 1.20 to officially get into distros such as Ubuntu (bug) and Fedora (bug)officially, and then they won’t deliver bug fix updates. This is partly due to lack of the volunteer packagers’ time and partly due to unfriendly distro policies towards applications. My only hope now is something like Glick.

The next article in the series about Qt Quick best practices has been published (but don't miss out the other one about property bindings). This time, I talked about Components, and how they can help to keep your QML code clean and maintainable. The team behind the N9 Developer blog has been a great help to me, especially Ville Lavonious and Matti Airas. I am also thankful for the additional input (and proof reading!) from Jon Nordby and Sauli Kauppi. Thanks guys!

I recently pushed the Maliit team here at Openismus to tidy up the website, to make the current status clearer. Here is a summary:

Maliit is the only open-source input system that offers the features real products need, allowing on-screen keyboards for all the world’s languages. It is mature but it needs more work. This is the right project at the right time for various desktop projects to work together instead of having separate hacks that don’t please users.

Everybody loves the virtual keyboard on the N9, which Openismus worked on. That is the Meego Keyboard, which is built on the Maliit framework. It performs. It’s largely open-source, but it is fine-tuned for the N9′s MeeGo 1.2 Harmattan. It has an unfortunate dependency on libmeegotouch, which few developers love.

The newer Maliit Keyboard does not depend on libmeegotouch, though it does depend on Qt and QML. With enough effort, the Maliit Keyboard could be as good as the MeeGo Keyboard.

The underlying Maliit framework API has been thoroughly tested and iterated by these keyboards and by other input methods, both open source and proprietary. It has had many contributors, has gained many regression tests, and is run by people who care deeply about quality.

Note that Maliit is not trying to be an on-screen keyboard for accessibility.

GNOME

We’d like GNOME to allow use of Maliit so people are not forced to use the current Caribou keyboard that only works with GTK+ applications and doesn’t offer features such as CJK or word prediction. We know that GNOME doesn’t want a hard Qt dependency. Of course that would be silly. We do want cross-platform compatibility. We also think that this is a large problem space that GNOME cannot tackle alone.

That would need gnome-shell (or its St toolkit) to support GtkIMContext as Maliit uses it. However, the gnome-shell developers currently feel that any on-screen keyboard (or input method UI, I think) must be part of gnome-shell’s own source code, and can’t be a separate process. Even if caribou could be made to work with non-GTK+ applications, a gnome-shell dependency is an even bigger block to cross-desktop adoption than Qt. So I really hope that this hard problem can be solved, though I do recognize that it’s hard.

The IBus implementation in gnome-shell seems to be hitting several similar issues (1, 2, 3), impacting CJK users even without a virtual keyboard. When they are fixed, maybe Maliit will work better. Note that, though Fedora has replaced SCIM with IBus, neither are really an issue for the on-screen keyboard, because IBus doesn’t let you show windows such as keyboards. However, the non-UI engines in the IBus plugins could (and probably should) be used in Maliit plugins.

I have some more notes about the current gnome-shell virtual keyboard here.

Unity (Ubuntu)

We’d like Ubuntu to use Maliit. We don’t know of any problems with that now, though I guess this depends on the GtkIMContext support in Unity’s nux toolkit library. We will do some tests on the WeTab soon.

Update: We published some Maliit packages for Ubuntu Oneiric in our PPA and we were pleased to find that nux seems to support GtkIMContext so you can, for instance, use the Maliit keyboard in the Dash’s search field. There are a few problems (1, 2, 3) but they seem fixable. There are also some generic GTK+ problems, but these are not blocked by anything fundamental in Unity.

Ubuntu currently ships Onboard, though that’s apparently just for accessibility.

KDE and Qt

We’d like KDE to use Maliit for their tablet efforts. The Maliit keyboards work today in Qt and KDE applications, though I don’t know if that means that they work in Plasma too. They have a Plasma keyboard (source code) already, and there seems to be interest in using Maliit instead of, or as a base for that. That would give it features that it apparently lacks, while also sharing the maintenance workload.

I recently made sure that Glom is not vulnerable to common SQL injections, which can risk destroying your data or providing unintended access to data. I’m mentioning it here so people can tell me if it’s not good enough. Be kind.

For the regular Glom desktop UI, it’s probably not a big issue, because only a small number of users have access anyway. But I believe in doing things properly and this certainly is an issue for Online Glom (more about that soon).

It turned out that things were mostly safe already, thanks to our use of GdaSqlBuilder instead of raw string concatenation. We still build a few special queries manually, to change database structure or permissions, and those would never be used by Online Glom, but I fixed (1, 2, 3, 4) them anyway. As a bonus, this avoids problems with special characters. Vivien Malerba, who is always incredibly helpful and responsive, fixed some related issues (1, 2, 3, 4, 5) in libgda.

I added some SQL injection tests to make sure. I would welcome ideas (or patches) to test extra vulnerabilities. Like all of Glom’s tests that use an actual database, this tests libglom with both PostgreSQL and SQLite, though SQLite isn’t used by the regular Glom build.

Likewise, I made sure (1, 2) that we use g_shell_quote() when building shell commands, for instance to invoke (spawn) postgres or tar. Of course, I would rather not do that anyway. And I made sure that we properly escape values in our database connection strings.

From the release notes: "Miniature now supports different languages thanks to a determined community of translators. Thank you for your effort! This is why we are dedicating this release to the first international chess tournament, celebrated in London on 1851.

Miniature 0.5 is being released for MeeGo Harmattan (Nokia N9 & N950) and Maemo (Nokia N900). Thanks to everybody involved in the initial Maemo attempts and the experimental version that was made available after the Miniature 0.4 release."

We also improved usability, compared to the previous release, but there's still a ton of work left.

A bit of history

I started working on Miniature – a chess client for freechess.org – in November 2009, after reading the Call for Contributors. Even though we had a pretty cool P2P feature (based on Telepathy and developed mostly by Dariusz Mikulski), it never quite reached the original goal: playing chess online. Back then I was learning how to create UI's with Qt Graphics View, which was all the rage at the time. Well, we now know that writing real UI's with that technology is a major PITA, but for my pet project, it was just too much. I got lost in the struggle.

For the next 18 months, Miniature was basically dead. Another failed project that started so promising. Quim did not want to give up though. After the N9 announcement, he launched a second Call for Contributors.

Perhaps I responded to his mail because I was embarrased at the idea of people wasting time trying to salvage the working parts of Miniature; there simply wasn't much to salvage! So I started again, this time with a very clear goal: online chess, and online chess only. Let others create the actual UI and whatnot. Focusing on one prominent feature and not having to worry about the UI worked well for me, even though I had to iterate over some architecture ideas until I felt comfortable. Quim in the meantime started to prototype the UI with QML. It was impressive to see his results, a level of polish I could have never achieved with my Qt Graphics View approach. At some point the backend was good enough to be sewn together with the frontend and suddenly we had achieved where I failed before: A touch enabled chess client for the N9 that can play chess online.

Having my own useful application available on the N9, published through OVI store, means a lot to me. I hope others will enjoy Miniature as much as we enjoyed re-creating it the second time around.

Usually AEGIS, the N9's security framework, protects system packages from being replaced. As such, files belonging to a system package can't be overwritten. And that's definitely a good thing, because otherwise each download from OVI store would put the user at a considerable risk.

Maliit is such a system package, but its flexible architecture allows for a creative way to replace the MeeGo Keyboard with a more recent version. This can be useful if you want to testdrive new features and to … nah whom am I kidding, it's purely for fun!

Be warned though, the following hack requires you to enable developer mode on your N9. Don't ever activate it unless you're absolutely sure what you're doing to your N9. It would be unforgivable to brick this beauty because of some misguided hack the planet attitude.

First we need to find a MeeGo Keyboard tag that will be compatible with the installed Maliit framework version on your device. Check that the output of

$ apt-cache showpkg meego-keyboard

matches the dependencies mentioned in the tag's Debian control file and the packages installed in your scratchbox ARMEL target.

Apply the community patch on top of the chosen tag. It renames the package to meego-keyboard-community and only installs the plug-in's .so file, together with a renamed CSS file (libmeegotouch requires that CSS file names match with library names).

This mean that we won't uninstall the regular package, as we still depend on most the other files that meego-keyboard installs.

Now build the Debian package. Copy it over and login to the device, then gain root access via devel-su. It's recommended to make a backup of /usr/lib/meego-im-plugins before installing the package.

After installing libmeego-keyboard-community, remove libmeego-keyboard.so from /usr/lib/meego-im-plugins, to avoid in-fights between the two plug-ins. Use

$ gconftool-2 -s /meegotouch/inputmethods/onscreen/enabled -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]
$ gconftool-2 -s /meegotouch/inputmethods/onscreen/active -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]

to activate the community plug-in. The language settings applets will most likely get confused, so be prepared that enabling new language layouts might only work directly via GConf from now on.

Gain user access and kill meego-im-uiserver. It should now load the new community plug-in. If you want to get the original MeeGo Keyboard back, uninstall the community package and copy the .so back from your backup. Alternately, you can try to reinstall it:

$ apt-get install --reinstall meego-keyboard

Have fun!

I am writing a series about best practices in using Qt Quick. It will be published on the official N9 Developer blog. The introduction and first article have already appeared. Your feedback on that series is very much welcomed.

Maliit really needs a non-MeeGo bugzilla, but we don’t want to install and maintain our own server. Unfortunately, freedesktop won’t let us in.

Are there any other reasonable options? We would like to avoid dealing with non-bugzilla bug trackers.

If we need to pay someone, has anyone had a good experience with a company that does this?

So far, using Maliit's virtual keyboard in GTK+ applications required fetching and compiling a GTK+ input method brigde yourself. Not any more. With the latest release, GTK+ applications should just work out of the box, thanks to Jon's integration efforts. Right at the same time, Łukasz was looking into using Maliit together with GTK+ applications on his Ubuntu desktop. He did a great job testing Jon's improvement and also contributed patches to properly update GTK+'s input method module cache. When compared to the Qt support, the gap in terms of supported features is quite large. We would like to further improve the GTK+ support and contributions are certainly welcome.

GTK+ application support for Maliit input methods has existed for a long time, but up until now it has lived in separate repositories. This has been inconvenient for users and for developers, and was the major cause for it to not be on the same level as the Qt support. This has changed as the GTK+ support has now been merged into the maliit-framework repository, and along side the Qt support. Maliit 0.80.8, which was released yesterday, contains these changes.

Two implementations existed for Maliit GTK+ support. One was written by Javis Pedro as part of a Google Summer of Code project for MeeGo in 2010. His blog has several posts on the topic. The other implementation was maintained by Raymond Liu (Intel). This is the implementation shipped in Meego Netbook, and the one improved by Claudio Saavedra (Igalia) as part of the GTK+ on MeeGo project. It was also the only one that was updated to work with the DBus connection changes that was done quite some time ago, and supporting both GTK 2 and 3. For these reasons this was the implementation integrated into mainline Maliit.

Once the code was integrated, improvements soon followed. The application now correctly reconnects to server, and make install will automatically update the GTK+ input module cache on Ubuntu, thanks to Łukasz Zemczak (Canonical), and on Fedora. This means GTK+ application support will work out of the box, no twiddling needed.

While this is a huge step in the right direction, the GTK+ support is not as good as for Qt yet. Javis Pedros implementation has features that does not exist in mainline, so code/principles can hopefully be reused from there to implement these. This includes custom toolbars and attribute extensions, and content type hints for text entries. Other features looks hard to implement due to limitations/differences in the input context plugin architecture found in GTK+, and will probably need work in GTK+ itself to solve.

Had a few problems focusing on my work today, so I came up with this little hack: A script converting devhelp books into Qt help collections.

Together with QtCreator's autotools plugin it should help turning QtCreator into a proper GNOME IDE.

Next steps: Let QtCreator index devhelp books automatically. Also on my wishlish: A code model for GObject properties and signals, and Glade integration.

Well, now back to real work.

Krzesimir Nowak joined Openismus in the beginning of August this year. Not only is he a very talented developer (or, as I once said, the first one to actually fill the gap Daniel left), but he's also fun to work with.

Just before I went on my vacations in September, I left him with some nice tasks to improve one of the cool features in Maliit: Dynamic key overrides. The way I had set up the tasks I knew he would trip over bits of hideous code and seeing how he could deal with it was part of the exercise.

For now, Krzesimir's work on Maliit is finished. With 25 commits, two of them being bug fixes in said ugly code, Krzesimir did an outstanding job while thoroughly understanding and fixing one of Maliit's core features in a rather short time span. Of course he will tell you that it took him way too long ;-)

Thanks for your contribution, Krzesimir, and well done!

After finishing my work on Syncevolution's build system I was asked to get in touch with Maliit. My new task was to write some examples showing how to use dynamic key overrides in both application and plugin side, simplify a bit the use of them in application side and implement key overrides handling for QtQuick plugins.

Examples

Key overrides are useful because they allow application author to make action key (this is what we usually call "Enter") of virtual keyboard have different caption (e.g."Send" in an instant messaging application) instead of standard bent arrow icon. Imagine having an application which logs you to some online service - all it could have is two fields, one for login and another one for password. Depending which of this fields has focus the action key caption could be "Next" or "Login" respectively. In fact, I wrote a sort of mockup showing it - it is called twofields:


There are also examples of C++ and QtQuick plugins reacting to changes of action key caption. You can find them in examples directory in Maliit framework repository.

Simple overriding

Overriding a key from application side is done in three steps:

1. Create Maliit::AttributeExtension.
2. Call setAttribute method of Maliit:AttributeExtension.
3. Bind attribute extension to some input widget.

Previously the third step was a bit messy - you had to subclass an input widget and override its inputMethodQuery() method to return an id of attribute extension:

class MyLineEdit : public QLineEdit {
public:
    MyLineEdit()
        : QLineEdit(),
          extension (new Maliit:AttributeExtension)
    {
        extension->setAttribute("/keys/actionKey/label", "Wheee");
    }

protected:
    QVariant inputMethodQuery(Qt::InputMethodQuery query) const {
        typedef Maliit::InputMethodQueryExtensions MaliitQuery;

        MaliitQuery maliit_query(static_cast<MaliitQuery>(query));

        switch (maliit_query) {
        case Maliit::InputMethodAttributeExtensionIdQuery:
            return QVariant(extension->id());
        default:
            return QLineEdit::inputMethodQuery(query);
        }
    }

private:
    QScopedPointer extension;
};

Now, forget about the above code. The one below will do:

Maliit:AttributeExtension* extension(new Maliit:AttributeExtension);
QLineEdit* line_edit(new QLineEdit());
extension->setAttribute("/keys/actionKey/label", "Wheee");
line_edit->setProperty(Maliit::InputMethodQuery::attributeExtensionId,
                       QVariant(extension->id()));

All names of properties are in maliit/namespace.h.

Key overrides in QtQuick plugins

QtQuick plugins now also can have overriden action key. It is a matter of some property bindings and setting a default icon or label. Below is very minimal QML code that could represent an action key. Obviously, some styling and sizing should be done also, but were stripped for clarity.

Rectangle {
    id: action_key
    property string caption: MInputMethodQuick.actionKeyOverride.label

    MouseArea {
        id: mouse_area
        anchors.fill: parent
        onReleased: { MInputMethodQuick.activateActionKey() }
    }

    Text {
        anchors.centerIn: parent
        text: caption
    }

    Component.onCompleted: {
        MInputMethodQuick.actionKeyOverride.setDefaultLabel("Enter")
    }
}

Note that only actionKey overrides are supported in QtQuick plugins. There is a plugin that already uses it - meego-keyboard-quick. For those who want to know how to write Maliit plugins in QtQuick, Michael Hasselmann wrote a short tutorial about it.

We released Maliit 0.80.7 on Friday. Over these last days, I am doubly proud about our project. Not only did the N9's virtual keyboard get astonishing reviews across the board, but what's even better: We managed to keep this software open-source. In our communities, there will always be those who focus too much on technical aspects. I remember the technical struggles we had even within MeeGo! But now we get feedback from real users who couldn't care less about what Qt or MeeGo Touch is, and to be honest, that's a refreshing change.

Being here at Qt's Developer Days 2011, it feels great to get such feedback directly, from first-time users of the Nokia N9. Especially the fine haptic feedback and the keyboard's accuracy gets noticed.

I also had the possibility to see a Japanese input method — running on the N9 and powered by Maliit. Seeing how well this plugin already integrates with the platform, I feel that our architecture yet again has been justified. I am looking forward to see more Maliit plugins, and more platforms using Maliit!

Funny posting on planet gnome today: A message to liberals. No comments enabled on that blog. Not nice: Post to some closed circle (forum, social network, ...) if you fear feedback.

Anyway.

A quick look at the situation in Greece and UK should be enough to understand where this is going.

In Greece was ruined by some pervert kind of socialism: Use cheap money to give the population unreasonable gifts, to ignore tax evasion, to bloat public service beyond all sanity, to pay unreasonable wages.

UK is a different story, they indeed have some quite liberal society. To me it seems they somehow failed to regulate their finance market by a) not properly taxing it b) moving the risk from share holders to tax payers c) letting banks betray citizens by handing out unjustified loans. This all caused a giant finance bubble and massive brain drain in producing industries.

Notice that in liberal theory governments are required to create proper basic conditions, enforcing sane behavior. Letting people just do what they want is anarchy, not liberalism.

In August Openismus asked me to work on Syncevolution's build system. The most important part of this work was to convert it from recursive Automake to non-recursive one with some features from previous build system still being available. Those were namely version number generation and, if possible, avoiding of manual listing of files to distribute. An added value of this conversion would be faster parallel build. Also additional objective was to make the build system less confusing for newcomers, but I doubt if I succeeded in that one.

Before I started the work the build system of Syncevolution consisted of two
sort-of-configure.in files (configure-pre.in and configure-post.in), Makefile-gen.am in src/, gen-autotools.sh, configure-sub.in files in every backend directory and a bunch of regular Makefile.am files. How this worked? autogen.sh was calling gen-autotools.sh creating proper configure.in by sandwiching contents of all configure-sub.in files between configure-pre.in and configure-post.in and substituting the version in AC_INIT with the one it computed. Also it was doing some find-and-sed magic on Makefile-gen.am to generate Makefile.am with list of found backend directories for SUBDIRS variable. After finishing this steps, it called autotools. In different order than autoreconf is doing it, but that was minor issue. Pretty messy, eh? Another issue was toplevel Makefile.am and src/Makefile-gen.am being a mess - lots nested ifs mixed with some custom rules and variables here and there.

While I liked the idea of injecting contents of configure-sub.in into final configure.in I didn't quite like how it was done. I wanted autogen.sh to call just autoreconf with some flags. I wanted no sort-of-configure.in files. I wanted no Makefile-gen.am. I wanted no script doing sed on neither configure.ac nor Makefile.am.

For version number generation I just stole an idea from autoconf (it uses m4_esyscmd in AC_INIT), so now it calls gen-git-version.sh.

I put code injecting contents of configure-sub.in files inside a m4 macro (which in fact calls a script) so merging of sort-of-configure.in files into configure.ac was possible.

Doing magic on Makefile-gen.am was apparently not needed after conversion to non-recursive Automake, because SUBDIRS are rather not used there. Instead, the backends.am with 'include <backend_name>/<backend_name>.am' lines is generated by yet another script.

Above steps clearly don't help the readability of build system. Maybe at some point such tricks could be removed.

Automake's documentation says that Automake itself should have enough support for generating a non-recursive build system. But still there were some hurdles to clear.

1. Automake has a useful feature of installing/distributing the directory structure without need of specifying foodir and foo_DATA variables for every subdirectory - it is a nobase_ prefix. Apparently it is not that very useful in non-recursive Automake. Why? I wrote it in detail in feature request I reported to Automake.
2. At some point 'make -j4 distcheck' failed. After some digging I noticed that libtool was trying to relink a backend against a library that should be installed at that point but it seemingly wasn't. That looked like a race condition because of incomplete dependencies. There are already some reports/feature requests for ability to specify install-time dependencies. In general Automake generates install-am rules as follows:
   
   

   install-am: all-am
    @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
   

   
   so install-exec-am and install-data-am can be executed in parallel. install-exec-am rule installs all libraries, scripts and programs that should reside directly in one of standard directories ($(libdir), $(bindir), $(libexecdir) and so on), while install-data-am installs the rest. So a library is installed during install-exec-am and backend during install-data-am. And seemingly thread doing the latter rule installs (and relinks) the backend before the library is installed.
   
   My temporary hack was just to override install-am rule to do these steps sequentially:
   
   

   install-am: all-am
     @$(MAKE) $(AM_MAKEFLAGS) install-exec-am
     @$(MAKE) $(AM_MAKEFLAGS) install-data-am
   

   
   This is ugly because it invades Automake's namespace.
   
3. The task of distributing files, that is - creating a tarball is a special task of Automake. The list of files to distribute is independent from conditionals. Unfortunately Automake's documentation is not clear about it. The misunderstanding of this issue often leads to a situation like the one below:
   
   in configure.ac:
   
   

   # need rst2html for HTML version of README
   AC_ARG_WITH(rst2html,
               ...,
               [AC_PATH_PROG(RST2HTML, rst2html, "no")])
   AM_CONDITIONAL([COND_HTML_README], [test "$RST2HTML" != "no"])
   

   
   in Makefile.am:
   
   

   if COND_HTML_README
   dist_doc_DATA += README.html
   endif
   ...
   README.html: README.rst
     $(RST2HTML) --initial-header-level=3 --exit-status=3 $< >$@
   

   
   Often justification for such situation is to avoid hard dependency on rst2html but still be able to provide README.html in tarball. Now, if one clones the repository, calls autogen.sh to generate build system, then calls configure with --with-rst2html=no (or just configure, if rst2html is not installed) to generate Makefiles and then calls make && make dist to build project and generate the tarball then the build will fail during executing dist target. That is because make wants to put README.html into tarball thus it executes a rule generating it. But RST2HTML variable is 'no'. This often goes unnoticed for long time. Why is that? Because automake strives to make tarballs having always the same content, regardless of flags passed to configure, regardless of existence of some installed software. Tarballs have to be always the same. With this in mind there are two clean solutions to this situation: either never distribute README.html or always do it. For the former changing the line:
   
   

   dist_doc_DATA += README.html
   

   into:
   

   nodist_doc_DATA += README.html
   

   should be enough. For the latter - make rst2html a hard dependency and thus remove the
   

   COND_HTML_README

   conditional.
   
   There is also sort of solution for having README.html always distributed:
   

   dist_doc_DATA += README.html
   
   if COND_HTML_README
   
   README.html: README.rst
     $(RST2HTML) --initial-header-level=3 --exit-status=3 $< >$@
   
   else
   
   README.html:
     if test ! -f README.html ; \
     then \
       echo "no rst2html and README.html is not found!"; \
     exit 1; \
   fi
   
   endif
   

   Understanding of this solution is left to reader as an exercise.
   
4. Since non-recursive Automake means that only one Makefile (a toplevel one) is generated that forces developer to be careful when using variables. That is because all .am files are included into toplevel Makefile.am and thus it may happen that some variables are clobbered. To avoid clobbering a variable meant as internal one (say: my_sources) it is good idea to prefix it with escaped path of this .am file, for instance src_dbus_server_my_sources. To avoid clobbering an Automake variable (say: lib_LTLIBRARIES) it is good to initatialize this variable at the beginning of Makefile.am with an empty value and later just append values to it:
   
   

   # beginning of Makefile.am
   lib_LTLIBRARIES =
   ...
   # some where later or in another file being included by Makefile.am
   lib_LTLIBRARIES += src/foo/libfoo.la
   src_foo_libfoo_la_SOURCES = ...
   

   
   Since I had like twenty of such variables (MAINTAINERCLEANFILES, DISTCLEANFILES, bin_PROGRAMS, dist_noinst_DATA and so on) I created a separate setup-variables.am file which contained only such initializations and included it in toplevel Makefile.am.
   
   Also, with such system not only variables may be clobbered but also some local rules meant to be run as hooks like installcheck-local or some special make variables (.PHONY). My solution was to add lines to setup-variables.am:
   
   

   all_dist_hooks =
   all_phonies =
   

   
   Add lines to toplevel Makefile.am:
   
   

   .PHONY: $(all_phonies) ;
   
   dist-hook: $(all_dist_hooks) ;
   

   
   And to .am file with dist check routine:
   
   

   all_dist_hooks += src_dist_hook
   src_dist_hook:
    ...
   ...
   all_phonies += $(TEST_FILES_GENERATED)
   $(TEST_FILES_GENERATED):
    ...
   

5. Another not documented (or maybe a bug) was that one have to define explicit foo_DEPENDENCIES variable when foo_LIBADD (or foo_LDADD) has AC_SUBSTed variable containing a path to in-project library. Otherwise Automake won't generate dependency on such library and race condition ensues (foo may be linked before the library is build). This is written in detail in bug report I filed.
   

When I'm filing bug reports to any project I try to at least look where the problem in source code is and to create a patch. But Automake being script of 8k lines of scarcely documented functions scared me away - I suppose that modularisation should be performed earlier instead of writing such a monster. Maybe later I'll try looking at it again.

In the end I must say that I am not happy with the outcome. Probably some generated files does not need to be generated anymore, so they should reside in repository, be visible for newcomers and scripts previously generating them removed. That would for sure improve clarity. Toplevel Makefile.am and src.am in src/ are still a mess. configure.ac is still also a mess. Also non-recursive Automake being less confusing to newcomers is questionable. I suppose that most of people using Automake is used to recursive build system and tend to treat .am files as Makefile.am files. Which is obviously a pitfall, because $(srcdir) and $(builddir) change their behavior. But I suppose that Autotools are in general confusing for newcomers.

tl;dr - I noticed that when converting a recursive complex Autotools based build system (such as Syncevolution had) to non-recursive one, some problems never appearing before may (or rather: will) appear. Some of them appears to be an effect of not being documented clearly in Automake documentation.

Very sad day. World lost one of its biggest geniuses. Steve, thank you for your awesome ideas! Life would be so much more boring, so much more complicated without your contributions.

illustration by jonathan mak

tl;dr: If you’d like to help improve phone synchronization support, please run the script linked to at the bottom and send me the file it produces so that I can compile a list of supported phones.

As Murray pointed out, I’ve been working on SyncEvolution for the past couple months. Recently I added support for getting reliable phone information using the Bluetooth Device ID Profile (DIP). This data is used to match a Bluetooth phone with suitable syncEvolution configuration templates. In syncEvolution, templates are predefined in order to make setting up a sync session easier and less error-prone.

The problem with using the DIP information is that it’s just a hex number. For this information to be more useful, we need mapping from IDs to names. A list of companies IDs is freely available. For products this is a different story. As each company assigns numbers to its products, there is no centralized list mapping products to their assigned IDs.[1] So, we have to make our own list.

Below is a small python script that checks if your phone supports the Device Id profile and asks you for the model of the phone. It produces a file that you can either attach to, or copy into, an email and send to me (email address is in file). Oh, and don’t forget to turn on your phone’s bluetooth.

Bluetooth Device ID Inspector

Thanks!

[1] If anyone has device ID to product name mappings for a particular manufacturer we’d be grateful to have this info.

Currently Maliit depends heavily on X for core functionality (for example assigning the virtual keyboard to the application via transient for window hint) but also for some optional features like self compositing, which was implemented to dramatically improve the performance on Harmattan by doing the compositing inside Maliit itself instead of inside the X compositor.

Still our target is to support also non X platforms like Wayland, which is currently planned to be used in Meego in future (see Wayland in Meego 1.3). As a first step in this direction we made X optional in Maliit. Than as a second step we implemented basic support for Qt 4.8 Lighthouse. Qt Lighthouse provides support for different backends like for example Android, xcb and Wayland. Compiling Maliit with that Qt version allows it now to run Maliit on Wayland. Next step is to implement better support for Maliit in Wayland like a window management policy.

I have a strong preference for music in a language I can understand, if nothing else than for the opportunity to mumble along. But “Návaz”, the latest album from Czech band Silent Stream Of Godless Elegy, is a little gem, even if I can’t understand a word of the Czech lyrics.
Návaz, like the previous albums is a doom metal album with strong influences from Moravian folk music and lore. What I like most about this album are the heavy contrasts: Quick, playful violins against slow, drudging guitar riffs; soft female voice against harsh male voices; traditional folk instruments and musical themes against modern metal.

Here is the opening track, Mokoš, which I think is quite representative:

 

Those who don’t have the stomach for the above, thinking it is too noisy, might still enjoy the songs Sudice or Samodiva. More samples are available on their Myspace page. You can find the album at Amazon.

If you liked this music you should also consider checking out In Via (2010) by Illuminandi. Style wise it leans closer to gothic metal, more gloomy and bleak, but overall very much the same type of feel.

 

Some while back I added basic GObject Introspection support to GEGL and GEGL-GTK master a while back. This will* allow application developers to write their Gegl + Gtk based applications in any language supported by GObject Introspection, like Python, Vala and Javascript. For GeglQt, the Qt integration library for using Gegl in Qt based applications, it was natural to use PySide to provide Python bindings for it. The initial setup was quick and easy, thanks to the binding tutorial, but there was one challenge.

The current widgets provided by GeglQt are for displaying the output of a node in the GEGL graph. Therefore they have methods with the following signature to hook up it up:

From gegl-qt/nodeviewwidget.h
GeglNode *inputNode() const;
void setInputNode(GeglNode *node);

GeglNode is a GObject (from the C based glib) subclass, and without help the bindings generator (Shiboken) does not know what to do with it so the method cannot be bound. PySide could have been used to also generate bindings for Gegl itself, but what we actually want to do is to make use of the existing PyGObject based bindings.

Marcelo Lira on #pyside let me know that this should be possible by adding some annotations to the typesystem.xml file, and implementing a Shiboken::Converter<T>. It is indeed possible, and for the above type looks something like this:

From typesystem_gegl-qt.xml
<primitive-type name="GeglNodePtr">
      <conversion-rule file="geglnode_conversions.h"/>
      <include file-name="pygobject.h" location="global"/>
</primitive-type>

From geglnode_conversions.h
namespace Shiboken {
template<>
struct Converter<GeglNodePtr>
{
    static inline bool checkType(PyObject* pyObj)
    {
        return GEGL_IS_NODE(((PyGObject *)pyObj)->obj);
    }

    static inline bool isConvertible(PyObject* pyObj)
    {
        return GEGL_IS_NODE(((PyGObject *)pyObj)->obj);
    }

    static inline PyObject* toPython(void* cppObj)
    {
        return pygobject_new(G_OBJECT((cppObj)));
    }

    static inline PyObject* toPython(const GeglNodePtr geglNode)
    {
        return pygobject_new(G_OBJECT(geglNode));
    }

    static inline GeglNodePtr toCpp(PyObject* pyObj)
    {
        return GEGL_NODE(((PyGObject *)pyObj)->obj);
    }
};
}

The PyGObject C API and the GObject type system is here being used to implement what Shiboken needs. The attentive reader will note that GeglNodePtr is used and not GeglNode*. This is a simple “typedef GeglNode * GeglNodePtr“, which looks to be neccesary with current PySide (1.0.6) to avoid it being confused by the pointer. Hopefully that is fixable and won’t be necessary in the future.

With this solved, I committed the initial Python support to GeglQt master yesterday. It contains a trivial Python example showing the usage. Some build cleanups, binding generator tweaks and testing remains to be done, but expect Python support to be a prominent feature for GeglQt 0.1.0

 

* There are still a lot of GObject Introspection annotations missing in Gegl. See the tracking bug. Help wanted!

So, in the last couple of months I’ve been working a bit on GEGL. Some of the work has already been covered by LWN, so I guess it is time that I blog about it…

GEGL is a generic image processing library which is used by applications like GIMP, (and in the future maybe MyPaint and DarkTable). It provides applications with a graph based image processing backend that can do non-destructive processing of high-bitdepth images, among other things.

One of the problems that I think has been limiting adaptation of GEGL has been the entry barrier to starting to use it in a graphical application. While GEGL provides the image processing backend, it did not provide good and easy ways of displaying the output on screen. Now it does!

GTK+, Clutter and Qt integration libraries

Some code for integrating GEGL in GTK+ based applications has existed in the GEGL tree for a long time, but it was not well maintained and there was no public API. After brushing up the code to use Cairo for rendering and to support both GTK+ 2 and 3, it was split out to a separate library and repository: gegl-gtk. This library now provides a GtkWidget for displaying the output of a node in the GEGL graph, with basic support for scaling and translations. Any change in the GEGL graph will be reflected in the view widget. This makes it trivial for applications using a GTK+ based user interface to get started using GEGL, see for instance the provided examples in C or in Python.

The same functionality is provided for Clutter based user interfaces by gegl-clutter in form of a ClutterActor. This code was previously available as clutter-gegl, but has now been renamed and moved to be a part of the GEGL project, and is maintained by Øyvind Kolsås. Example code in C.

Last but not least, gegl-qt was created to serve the needs of applications using Qt based user interfaces. The different widget systems (QWidget-, QGraphicsWidget- and QML-based) are all supported. In addition to the features currently available in the GTK+ and Clutter versions, the Qt view widgets also support auto-scaling and auto-centering. Python bindings via PySide is planned, but blocking on a PySide issue at the moment.

A pretty boring screenshot showing two QWidget based examples (code: 1, 2) for transformations:

Artwork: “Wanted“, speedpainting by David Revoy

The first stable release of gegl-qt and gegl-gtk will hopefully be available soon. The list of tasks can be found in the README files.

Display operations

In GEGL, image processing is described as a graph of operations. “gegl:display” and “gegl:gtk-display” operations existed in the gegl tree, and by attaching one of these to a node in the graph one could display the output of the graph at the given node in a window . Such display operations are useful for applications that just want to show the output of a graph without having to use a GUI library directly.

The problem was that both of these operations were optional, so applications could not rely on this functionality to be present. This is solved by letting the “gegl:display” operation be a meta-operation, which uses other operations as a handler to actually display the output. Such display handler operations are now provided by gegl (optional, using SDL), gegl-gtk (using GTK+) and gegl-qt (using Qt). In addition a fallback operation that will export a PNG file and launch an external application to display it will be provided in GEGL.

More to GEGL stuff to come soon, hopefully.

This movie was nerve-wracking. A group of friends who share a passion for mountaineering meet for a trip into the wilderness. Things quickly go downhill from here (ha!), but compared to your traditional slasher movie (to be fair, this didn't feel like a slasher movie at all), our survivalists try to act intelligently. Hell, the whole story actually made sense!

But whenever I thought the featured cold-bloodedness is unreal, I had to remind myself of the Oslo shooting - which made the movie frighteningly real. Bad timing? Maybe, but still a good decision to show this movie.

Rounded up with an interesting soundtrack and gorgeous nature shots of the Scottish Highlands, the high IMDB rating feels well deserved.

Firefox 6 landed on my Ubuntu box, so obviously it's time for my mandatory Firefox rant...

top - 14:42:13 up  4:24,  7 users,  load average: 6.52, 4.21, 1.83
Tasks: 216 total,   4 running, 211 sleeping,   0 stopped,   1 zombie
Cpu(s):  5.0%us,  8.5%sy,  0.2%ni, 17.3%id, 69.1%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3951008k total,  3915284k used,    35724k free,     2500k buffers
Swap:  4001788k total,  1353916k used,  2647872k free,   335360k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
16775 mathias   20   0 5454m 2.8g  16m S    0 73.3   3:21.52 firefox-bin

This is with 6 tabs open: Bugzilla, Google, nothing heavy. Not funny at all.

Maybe a Firefox bug, more probably Ubuntu messing up with patching under time pressure.

Anyway: Time to read about quality management, to consider how mixing security fixes with feature releases impacts release quality, to consider how rushing releases impacts release quality.

Sorry for sounding arrogant while pointing out the obvious.

Update: Resetting layers.acceleration.force-enabled did the trick.

The Desktop Summit is almost over. I spent the core days there, mostly just meeting old friends and listening to parts of some talks. The whole event felt very smooth, in an excellent venue. There was just enough partying, though I always sneak away early to get some rest.

As Openismus has a large Berlin office, several employees volunteered to help with the organization. I hear they did a great job. Thanks to Chris, David, Jon, Kat, and Patricia. Only a little of their time was provided by Openismus, because I didn’t want the responsibility, so I can’t take the credit either – it’s all theirs.

Openismus also provided some space for the GObect+Introspection hackfest over the last 3 days.

I’m not a fan of KDE and GNOME combining their conferences. I think GUADEC (and Akademy) should inspire developers, herding them in a common direction, but it’s tediously hard to focus on our core values while surrounded by others who simply don’t agree. But I’m not particularly relevant to GNOME these days so my opinion shouldn’t count for much, and people seemed to like it last time.

I do love Berlin and it’s great to see others discover it too.

 

 

 

If you’re a fan of traditional progressive metal, you might want to check out Lost in Thoughts debut album: Opus Arise.

Released April 29th this year, Opus Arise features some very solid songwriting much in the style of Dream Theater and similar bands. The musicianship is generally excellent, and the production is stellar. On the downside, this is not a very original album by any measure, you will not find too many fresh ideas or expressions in this album. So if you’re looking for something that takes progressive metal in a new direction; look elsewhere.

Here is the opening track, Beyond the Flames.

My favorite tracks include the slower Blood Red Diamond and the kicking closing track Assimulate, Destroy. You can find the album on Amazon.

Sadly the band had a car accident on their first European tour in late May, which left the drummer with a broken leg and having to undergo surgery. A news post comment from the drummer, and a recent interview seems to indicate that the recovery so far is going OK. Hopefully he will be fully recovered, back to playing drums, soon.

A friend told me that I should blog about music again. This was a shot at doing just that.

Visa authorities playing bad games with Chandni gave me the chance to talk about the QtContacts tracker plugin, which I and others where working on for that past few months. In case you've missed that early talk, here are the slides.

Interesting to just watch George from KDE to talk about similar things.

Seems premature bad taste becomes the norm in GNOME land.

• Hitler Video at Desktop Summit 2011
• EMACS virgin jokes at Desktop Summit 2009

Seems that video was shown at the desktop summit's GNOME: state of the union talk. Despite that the subtitles are entirely off, the German dialog behind is about the final days of WWII involving street fights and total destruction of Berlin.

That's nothing to make fun of. Is that really how GNOME wants to present itself?

This year’s Desktop Summit is taking place at Humbolt University in the middle of Berlin, one of the most interesting cities in the world. This makes it a prime starting point for taking a tour of the city. For this reason, we’ve designated some time on Thursday, August 11th for taking day trips.

When you come to registration on Saturday you’ll find representatives from some of the best tour operators in Berlin. Here’s what will be on offer.

• Walking Tour (€10): Hit the pavement with the guides from Insider Tours. They’ll give you some great insight into some of Berlin’s most interesting places.
• Bike Tour (€18): For the two-wheel inclined, the folks from Fat Tire Bike Tours would love to show you around.
• Segway Tour (€45): Hey, we’re all geeks, so maybe you’d prefer seeing Berlin from a gyro-balanced electric transporter. The folks from City Segway Tours can help you with that.

You should also feel free to book tours with other tour operators on your own. We’ve listed a few on the wiki for you.

Oh, and remember to sign-up for the Football and Volleyball matches taking place Monday, August 8th, 7-9pm if you want to play.

Evolution Data Server

Recently, MeeGo switched to GNOME’s Evolution Data Server for storage of contacts, calendar, etc, though not for the API, which remains QtContacts, via the qtcontacts-eds backend. To help with that, Openismus has been making e-d-s performance improvements for Intel. For instance, to avoid unnecessary transfer of data across D-Bus.

Tristan Van Berkom is doing the work, excellently as always, using upstream bugzilla, the mailing list, and upstream’s git.gnome.org. It’s gradually all going into the master branch. There are some special patches only for Meego’s branch, because it is based on the gnome-2-32 branch, whose API is partly deprecated in master. But we are taking the time to make equivalent changes in master’s new API.

We had worked on Maemo 5 (Fremantle)’s e-d-s fork, which used similar techniques to achieve the N900′s performance. But the developers weren’t given time to submit changes properly upstream. Also, some improvements were spread across other modules, some proprietary, though with hindsight the developers generally feel that many changes would have been better in evolution-data-server itself. It’s great that Intel are pushing for it to be done properly now.

Meanwhile we are also working on the qtcontacts-tracker backend alternative, which we like too.

SyncEvolution

At the same time, MeeGo switched to SyncEvolution for synchronization of contacts, calendar, etc with online services (via SyncML and other protocols) and with bluetooth phones. We are helping Intel with that too.

Chris Kühl has done some code cleanup which should hit the master branch soon and he is now letting SyncEvolution identify some phones via their Bluetooth Device ID profiles, where they exist. That could make configuration easier because the user won’t need to tell SyncEvolution what the phone can do or what quirks it has. Again, this is all via bugzilla, the mailing list, and gitorious, targeting the master branch.

Lastly, I’ve done some cleanup of the syncevolution.org website, simplifying its structure, and updating some text so it makes sense as a whole. I am still not fond of Drupal. David King wrote and updated the website’s documentation about the syncevolution command-line and GUI.

During the last months I've been working on Dolphin 2.0 which is planned to get released with the 4.8 release of KDE Applications. Dolphin 2.0 will get a new "view-engine" that will have several improvements in comparison to the current version.

Well, what means "view-engine" in the scope of Dolphin? The view-engine is responsible for showing the directory content as icons and text. In a very simplified form it can be seen as the sum of Dolphin's "icons mode", "details mode" and "columns mode".

The current version 1.7 of Dolphin is based on Qt's Interview Framework. Regarding the quality of the Interview Framework I'd like to quote a Qt developer from the Qt Labs Itemviews - The Next Generation  article:

"Not surprising. If you are using Qt, chances are you are using the item views. And if you are using the item views, you are likely to have an opinion about them. While using these classes you may have even form the opinion that they are not exactly the most shining example of Qt quality framework and API design. Let’s just say that there is room for improvement, lots of room! The symptoms are clear: the framework is generally too slow, unstable and the API is difficult to use. A clear case of overly complex design."

Having worked with the Interview Framework during the last four years I fully agree to this (... and probably would not have phrased it as friendly as in this quote ;-)). As an alternative for the Interview Framework a research project called Itemviews-NG has been created. After comparing Itemviews-NG with the view-engines-related code from libmeegotouch and Qt-Components it was clear that currently for Dolphin the Itemviews-NG would be the best choice. So the new view-engine for Dolphin 2.0 is build on a (very) modified subset of Itemviews-NG. In the longterm (probably with Qt 5) it is planned to integrate Qt-Quick but this affects only a non-critical minor part of the view-engine and has not high priority at the moment.

So much talk about the new base of the view-engine, but which benefits get the users of Dolphin by this?

Improved Performance

The new view-engine has been tested on a computer with a very slow hard-disk and developed with corner-cases in mind where the current view-engine had serious performance troubles. Now switching view-modes, zooming, resizing, ... is done with nearly no delay no matter how many items a directory has.

Unclipped Filenames

With Qt's Interview Framework having dynamic item-heights the way Dolphin required it was not possible. As workaround Dolphin used a fixed grid-size where the user could configure the maximum number of textlines. No matter which value has been used: Either the item-height got too large or the text got clipped like this:


Like most other filemanagers now also Dolphin is able to have dynamic item-sizes:


As a side-effect Dolphin 2.0 wastes less space and can show more items in parallel when using the same icon-size as the current Dolphin version.

Nonrectangular Item Boundaries

The Interview Framework only supports rectangular item boundaries. This means that moving the mouse above the position marked as red spot...


... results already in hovering the whole item:


The new view-engine provides optimized non-rectangular item boundaries:


So the hovering only takes place when the mouse pointer is above the the icon or text like in KDE 3 (Note that the look of the hovering is just a prototype and might change)

Grouping Support For All View Modes

Currently the "grouping" feature is only supported for the icons mode but will be available for all view-modes in Dolphin 2.0. I could not provide a screenshot yet as the code for grouping is still in a very early alpha-stage. In opposite to the current version of Dolphin grouping will not slow down the performance at all.

Animated Transitions

At the moment when removing or inserting items, changing the zoom-level or resizing the window the item-positions change magically from the original position to the new position. This sometimes makes it tricky for users to follow the new location of the items. With Dolphin 2.0 the layout-engine is fast enough to make those transitions animated. I don't like animations that slow-down the usage of an application so I took care to make them fast and unobtrusive.

From a developers point of view the new engine simplifies the maintenance a lot and lowers the barrier for developers to contribute patches for Dolphin. The code has been pushed to master today. Please note that the code is in an early alpha-stage and although the most tricky parts have been implemented already very basic things like drag and drop or selections have not been pushed yet. Those things are rather trivial to implement but it is still a lot of work and takes some time to have back the original feature-set. But I'm confident that everything will be ready until the 4.8 release of KDE Applications and hope that the new view-engine will justify the 2.0 version number :-)

Here’s a small update to my last post about the Desktop Summit social events.

By popular demand, we’ve reserved beach volleyball courts for your volleying pleasure. The time (Monday, 19:00-21:00) and location (see the map below) of the volleyball and football matches are the same.

You can sign-up for the volleyball match here and the football match here.

See you there.

View Larger Map

Meyah is now seven months old. She’s happy and active and brother Liam provides enough entertainment. She’s not quite crawling yet but she’s eager to start.

We in the the organizing team have now published the schedule for pre-registered Workshop & BoF sessions at the Desktop Summit 2011 in Berlin.

There is still time to register for ad-hoc sessions, and we will have two dedicated “hacker rooms” where you can sit down with like-minded people and work on what you like!

See the webpage for more information.

 

Looks like we have found and fixed the recent issues in the PulseAudio MediaServer2 implementation that led to weird behavior when trying to browse the PA server; it is available in PulseAudio master.

So after applying this, streaming from PA should be possible again if your client natively supports LPCM. If not, then most likely not. There seems to be an issue in setting up the transcoding (this includes the XBox e.g.)