Search:

Topics: Select category Maemo Downloads Maemo News Nokia N900 Downloads Nokia N900 News Nokia n900 Videos Uncategorized

Subscribe to PostsSubscribe to Comments

Customizing the MeeGo Keyboard

The look & feel of the MeeGo Keyboard (comes with the MeeGo Input Methods) can be easily adjusted to your needs. In the last post I already gave a brief example on how to modify the graphical assets. In fact, you will find that the look is mostly defined by the graphics contained in that one SVG file. The elements’ id’s are referenced from the keyboard’s CSS file, so it is a good idea to just leave them as-is, unless you really need more graphical elements. The CSS file is installed to a slightly different folder than the SVG file:

/usr/share/themes/base/meegotouch/libmeego-keyboard/style/libmeego-keyboard.css

If that looks a bit complex then it’s probably because it is. When hit by new design requirements we didn’t always manage to find a clean solution in time. But at least it works and there’s even documentation available.

Most containers are named MImAbstractKeyAreaStyle – they describe the style of the widgets that we use to represent keyboard layouts. You won’t find containers that describe the actual keys though (am sorry for that). Other than the CSS syntax, those containers don’t share much with regular CSS attributes – MeeGo Touch allows you to define your own custom attributes, and that’s exactly what I did, to quite some extent.

The whole keyboard responds to touch events or mouse clicks. That is, the reactive areas of the keys cover the whole keyboard. A single key’s reactive area is usually aligned with its bounding rectangle, unless spacers are involved. Spacers expand to fill the remaining width in a row, thus allowing flexible alignment of keys. Usability studies showed us that people expect a spacer’s area to be consumed by the reactive area of the neighboring keys. The diagram to the left visualizes how reactive areas are constructed from key margins, keyboard paddings and spacers. Keyboard paddings override key margins, e.g, the top margin of key is replaced by the top padding of the keyboard, if that key is located in the top-most row.

For each keyboard layout, the amount of keys defines its style mode (only works if the amount of keys is in range of 10-15 or 30-45 and if sync-style-mode-with-key-count is enabled). These keyboard layouts can get a fully customized styling on their own, e.g., different paddings, key sizes, images, etc. This helps with pixel-perfect designs, but can also be a lot of work.

We avoided to blend CSS attributes with the keyboard layout files, in order to keep the latter reusable for any kind of device. The basic idea is that – for a new form factor – only the CSS file would need to be adjusted. However, there are certain XML attributes in the layout files that can be controlled from the CSS file. For example: A row of keys can carry a height attribute (small, medium, large, x-large, xx-large) which is then mapped to key-height-* CSS attribute, where the concrete height of each group is eventually specified. Thus, the declarative nature of the XML files is preserved.

I hope this post made it less daunting to go and create your own MeeGo Keyboard design. I would love to see some concepts that could potentially replace the current design!