Tag Archives: Openismus

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.

Glom: Avoiding SQL Injection

General, ,

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.

Desktop Summit, Berlin

General, , ,

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.

 

 

 

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.

Glom: Storing PDFs

General, , ,

Glom already had an Image field type, letting you store pictures in the database and view them. It used GtkImage.

It can now store and preview PDFs, or anything else supported by Evince, via its evince-view library.

The contents can also now be opened in the external application via the context menu, and an Open With menu item even offers a choice of suitable applications via GtkAppChooserDialog. That’s why I haven’t bothered to add page navigation or zooming for PDFs in Glom itself.

It can even store arbitrary file contents, though it will just show a standard icon in that case. As a hack, it saves the contents as a temporary file in order to use GFileInfo to get the standard file icon. I haven’t managed to get the thumbnail via the G_FILE_ATTRIBUTE_THUMBNAIL_PATH attribute, but it’s probably not reasonable to expect to get that thumbnail for a completely new file.

In fact, I use the same temporary file hack to get the PDF data into the Evince EvView. I must figure out how to make EvView render from data in memory instead of a filepath.

It would be nice to show a simple video player for video files, but I haven’t found a suitable gstreamer-based library for that yet, though I guess I could copy/paste some code. And anyway, it doesn’t like huge files right now.

I use glib’s mime-type sniffing function to guess the mime-type, to decide how to display or open the document. This works surprisingly well but we really need to store the original mime type, and probably the file name, in extra database fields.

Update: I’ve given up on getting a thumbnail, so I’m just using g_content_type_get_icon(), which avoids the need to save a temporary file to disk. And for EvView, I’ll try to add API to allow loading from memory.

Glom: Simplified main window

General, ,

As planned, I have made the main Glom window even simpler. I’ve moved the table title down next to the “notebook” tabs, moved the records count up to the top. I’ve  hidden the “mode” concept because it’s now just a matter of whether you are entering find criteria or not. I’ve also removed the User Level menu, moving it’s toggle menu items to the top of the Developer menu, and I removed the User Level label, hoping that people don’t need that clue.

Before: Glom 1.18:

After: Glom 1.19/20:

(There are other differences between GTK+ 2, used by Glom 1.18, and GTK+ 3, used by Glom 1.19/20, and theme differences.)

Notice also that by using the custom-notebook widget, instead of GtkNotebook, the window does not need to be as wide as the widest notebook page even when that page is not actually showing.

This is in git master. I’ll do a new release when the dependencies get the tarball releases that I need. It will also fix the Find feature, which seems to have been broken in various ways since Glom 1.16.

Missing the Meego Conference 2011

General, ,

I won’t be at the Meego Conference in San Francisco this year. It would just mean too much time away when I should be taking care of my small children.

However, several Openismus people will be there to represent us: Ekaterina Gerasimova (Kat), Michael Hasselmann, David King, André Klapper, and Chris Kühl.

I will instead be taking my family to visit my side of the family in North Berwick, Scotland, where I’ll meet my nephew from New Zealand for the first time.

 

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.