Category: Software

Introducing; Maliit on-screen keyboard in Gnome 3

Posted on46 Comments

Maliit (also known as Meego Input Methods) has the following overall goal: “to be the input method project for MeeGo and other GNU/Linux-based embedded/mobile platforms”.

This initial video shows Maliit running in Gnome 3, and demonstrates some of the very basic features provided by Maliit and the standard keyboard shipped with it. The demo is done on a WeTab tablet running a standard Fedora 15 Beta, with the latest Maliit software installed. Jan Arne Petersen is working a bit on  Fedora packages, so hopefully it will soon be easy to install for those who are interested.

Some more info about the features shown in above video:

0. Theming. Using the theming support in the standard Maliit keyboard, it is easy to go from a mockup to ready implemented theming. This theme was based on the mockup from live.gnome.org (by Jakub Steiner I believe?) and done by Michael Hasselmann in a couple of hours. He also has a blogpost on how the theming system works.

1. Typing text.This is of course the number one feature of an on-screen keyboard. There are some essential best-practice and some tricks used in Maliit to be able to get really good reponse time and typing speeds. I hope we will have some blogposts about that soon.

Typing speed can be further enchanced by enabling multitouch support (not working out-of-the-box in Fedora due to missing support further down the stack), or by installing a prediction/correction engine. User feedback can be enchanced with audatory and tactile feedback (requires hardware and driver support obviously).

2. Different languages/layouts, and switching between them. Maliit comes with layouts for over 20 languages, tested and tweaked by usability experts. Latin, Cyrillic, Arabic and Chinese based scripts are covered. The layouts are defined by XML files, so one can easily change them if wanted.

Chinese ZhuyinRussian

Arabic

For more of the features offered by Maliit framework and standard keyboard, see the wiki page. If you are interested in improving Maliit, or its integration in Gnome 3 or other GNU/Linux environment, join the irc channel or mailing list.

Next up; the importance and difficulties of input method integration on touch enabled devices.

Going to Libre Graphics Meeting 2011 in Montreal!

Posted on1 Comment

So, it is confirmed, I’m going to LGM 2011! I was at LGM last year, and I expect this year to be just as good. Hopefully I’ll also be giving a talk this time, about MyPaint and/or OpenRaster.

If you are interested in free and open source graphics software, or the production of freely licensed graphical works, you should go too! See the press release for more information, or go straight to submit a talk proposal. If you cannot be there but still want to show your support, please consider donating.

I guess this means I should order the tickets soon…

cairooverlay: Generic Cairo overlay element for GStreamer

Posted on11 Comments

I wrote the initial version of this in late January, and after some interations it was merged yesterday to gst-plugins-good, and will be in gst-plugins-good 0.10.33. This solves the feature request I filed in 2009, one of my oldest bugreports in bugs.gnome.org!

What does it do?

cairooverlay allows you to draw arbitrary things on top of a video stream in GStreamer using Cairo. Previously you had to create a custom GStreamer element for that (in C/Vala), but now you can just hook up to some signals, using any programming language with GStreamer/Cairo bindings.

To draw an overlay using this element, you use the “caps-updated” signal to get information about the video stream (like width and height) and the “draw” signal to do the actual drawing. In addition to the Cairo context, the draw signal passes you the timestamp and duration of the buffer, so you can also do animations.

For more info see the included example application or the documentation (should be updated soon). Here is the obligatory screenshot showing the example application drawing a heart onto a test videostream:

GStreamer + Cairo = <3

The heart is actually animated, so I guess I should have had a video. But you’ll just have to trust me that it is very cute, or grab the code yourself!

FOSDEM 2011

Posted onLeave a comment

Last weekend I was in Brussels for my first FOSDEM.

Friday I attended a planning meeting for this years Desktop Summit. Several things were on the agenda, the most pressing being the website and the call for papers which both should be finished in the coming month. I was tasked with organizing the call for BoF/meetings/devrooms. In a broader scope, I see my role as making sure relevant non-KDE and GNOME projects know they are welcome. People involved in such projects are welcomed to submit talk proposals, or apply for space for a BoF/meeting just like a KDE/GNOME project, but for anything to come out of it we need to communicate this properly.

Didn’t go to a lot of talks, but I had plenty of good discussions in the “hallway track” and in the evening events. Especially good was meeting up with Claudio Saavedra to discuss Meego Input Methods and the Gtk+ integration he is working on. I hope I was able to help him a bit in getting started.

Attended the Libre Graphics Meeting planning dinner sunday evening. I don’t know if I’m able to make it to the conference yet, so I did not have that much to contribute, but I let them that Libre Graphics projects are welcome to the Desktop Summit. And that I might try to organize a MyPaint workshop at LGM.

Want to integrate with the Meego Netbook UX panel?

Posted onLeave a comment

It is not well communicated, but you can apparently write your own “tabs”/”panes” for the panel/toolbar found in the Meego Netbook UX. Hopefully this blogpost helps a tiny bit*.

As stated by the libmeego-panel/docs/README in the source tree of mutter-meego there are convenience APIs for GTK+ and Clutter based implementations. But it seems you can also just use the DBUS API, in case you prefer Qt or something else. I found this out by searching though meego.gitorious.org after someone asked on #meego

*Since this should be documented in the platform API, I’ve of course filed a bugreport.

MyPaint on Meego?

Posted onLeave a comment

When I got back from the Meego conference, I tried building MyPaint on the Ideapad I got (which runs Meego Netbook 1.1).

I was pleasantly surprised to find pygtk in the core repositories.  numpy on the other hand was missing but that was easy to build from source. Buut, it seems that pygtk is built without numeric support, making MyPaint unusable; numeric support is used to get access to the pixels in pygtk pixbufs, which we need for several central things.
I have of course filed a bug for this so hopefully it will be resolved soon. If not I will have to provide alternative pygtk packages using the community OBS. In any case, expect it to be working soon.

I also hope to adapt MyPaint’s UI to the handset and netbook/tablet form factor, but this is only talk so far.

Playing with Qt Quick; Imago

Posted on2 Comments

In learning Qt, I of course needed to get some experience with the newest and shiniest bits of Qt: Qt Quick.

One of the things I’ve done with that is to make a simple application, an image viewer called Imago. The code can be found at Gitorious. It is a bit different from typical Qt Quick applications as it is not a mobile application but rather targets the desktop. Thus I’m using standard desktop UI concepts like drop-down menues, and ordinary file-chosers.

Imago - single image view

Imago - single image view

Imago - "traditional" view

Imago - "traditional" view

Imago - grid view

Imago - grid view

The lists can be “flicked” through using the pointer, or using the scroll wheel. Moving between the views that show multiple images and the single-image view has a small animation.

Implementation

In a Qt Quick application two languages and runtimes are involved; C++ and the declarative language that forms the basis of Qt Quick, QML. Qt supports bi-directional communication between the two using a number of metods.
In my case I chose to make a QObject class that  maintains all of the central state in the application. This includes things like what folder is currenty open, the images in that folder, which image is currently focused/selected. All these attributes are implemented as QObject properties, and are notifyiable (meaning they have an attached signal that you guarantee to emit each time the value changes). Exporting this object to QML then allows these properties to be used in property bindings, or for one to connect to the notification signals.
So in Imago QML is basically used as a “stupid” UI layer for the image view. Other things, like window title and drop-down menues are handed by the C++ side, but by using the signals and properties of the same object.

Writing a desktop application means that one cannot assume a fixed window size like people tend to do for mobile device applications. With setting the resize property of the QDeclarativeView (the widget that displays the QML stuff) to QDeclarativeView::SizeRootObjectToView and using anchor layouts throughout this is possible, but it took me a good while to get working properly. Mostly because the concepts are new, and most (all?) the examples in the documentation seem to neglect this aspect.

The grid and traditional view are actually implemented in different QML files (though the delegate for the images in the list is shared). I did this to test how having several UIs would be like, and for a simple application like this it works out just fine.

Where to now?

Imago right now is very simple,  and could benefit from some added features and some designer love. I also just found a bug in the traditional view that needs to be fixed. I have documented these things in the README file in case someone is interested. As I have moved my focus over to other projects, I probably wont be taking this application much further, at least not at this time.

glom-postgresql-setup

Posted on1 Comment

Glom is an application that lets you design database systems, including user interface. It can be run as an ordinary application, and will set up and run a the database server for you automatically. But if you want to set up a shared instance, where several users connect with Glom to the same database, you typically want your database server on a dedicated server. And this can be a bit tricky to set up. So, glom-postgresql-setup was born; A dead-simple utility application to set up a PostgreSQL server for use with Glom. Like Glom, it is written in C++ using Gtkmm.

glom-postgresql-setup lets you to create a database user, and set up the PostgreSQL configuration to accept connections from external IPs. The UI is just a dialog with two fields and two buttons, dead-simple indeed. For now the application requires to be launched with superuser privileges, but before we encourage use of this tool we will of course implement proper privilege escalation using PolicyKit.
It would also be nice to be able to install and start the PostgreSQL server as well, but currently that is not so easy to do in a cross-distro way. Hopefully packagekit and systemd will help solve that, eventually.

Image preview support for OpenRaster in Qt working

Posted on2 Comments

While learning Qt here at Openismus I’ve written a basic, working plug-in for Qt that adds support for the OpenRaster file format*. Here is my Qt-based test application demoing this functionality by showing some awesome multi-layered abstract test art made by yours truly using Krita:

I asked for real art, but I did not get any

I asked for real art but as you can see, I did not get any.

The level of features supported is such that you will be able to preview OpenRaster documents created with applications like MyPaint, Drawpile, Nathive and GIMP, with the limitation that it will have a white background for transparent areas. The code can be found in qopenraster repository on gitorious (no tarballs), and the README file documents how to install as well as things that remain to be done.

The plug-in is basically a thin wrapper around libora, the OpenRaster reference library. libora takes care of parsing the OpenRaster document, reading out the layer data and rendering it into a single buffer. The rendering ability was added by me as part of this work, in addition to some other minor stuff. The Qt plug-in does RGBA to ARGB conversion and provides the QImageIOPlugin interface expected by Qt.

Doing this has also exposed several limitations and not-so-nice things in libora that should/needs to be improved. I’ve updated libora’s README file to reflect this.

*Assuming the Qt application actually uses QImage in a straight-forward way. The KDE image viewer Gwenview does not seem to use QImage directly, so you will not automatically get support there by installing the plug-in :((. I fear that other KDE applications might be the same, though I was not able to test Digikam. If anyone has a suggestion for a Qt based image viewer that works sanely in this area, don’t hesitate to leave a comment.

PS: I have an almost-working gdk-pixbuf module as well, will push that to gitorious soon.

First stable releases of misc. OpenRaster stuff

Posted onLeave a comment

Better late than never (links go to the announcements):

Packages for Arch Linux is of course available in AUR. I might also make some simple .deb and .rpm packages for this, users should not have to wait until spring to get easy-to-install support in their distribution.

The OpenRaster development tools (oratools), the reference library (libora) and qt/gdk support needs more love before we can tag 0.1.0 but hopefully it will be soon.