Tag Archives: Qt

Maliit: The only real on-screen keyboard

General, , , ,

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.

Update 2 much later: That must have been with Unity 2D, using Qt. Nux doesn’t have an input method abstraction as of right now, though it could.

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.

Openismus work on Evolution-Data-Server and SyncEvolution

General, , ,

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.

Openismus is Hiring

General, , , ,

Openismus is currently looking for a few experienced C++ coders, to work with our expert team in Berlin or Munich. We could really use some more Qt expertise. It’s an advantage if you have experience of GTK+ and GObject-based libraries too, though it’s not essential.

As usual, please email a description of yourself, along with a CV. I look forward to hearing from you.

Non-Automatic Layout is Useless / Qt Designer has bad defaults

General

The widgets in a UI should adapt to different window sizes, font sizes, translated text, left-to-right/right-to-left locales, etc. This is obvious to the programmers that I work with.

I recently remembered that qt-designer didn’t do this when I last tried, which shocked me. So I looked again at a newer version to see if it would make me happier. I took some side-by-side screenshots of Glade and qt-designer on my wide monitor, to make the point.

For instance, see the slideshow to experience the first-impression that a half-competent developer is likely to get. Buttons that were in the corner will be left stranded in a sea of blank space. Widgets will appear half out of the window.

All of this is unnecessary. qt-designer/qt-creator can actually do proper automatic layout if you right-click on the layout, and choose the “Lay out” -> “Lay Out in a Grid” menu item. The default is called “Lay Out in a Form Layout”. Presumably someone decided to make Visual Basic users feel at home by duplicating their stupid environment, but that just keeps them doing stupid things and makes regular developers go elsewhere.

By the way, I do like one thing in qt-designer more than Glade. It correctly assumes that a treeview is more likely than a text label to need to expand.

Note that qt-creator, which uses the same system, apparently via the same code, does the same thing. I checked the latest qt-creator snapshot.