Introducing; Maliit on-screen keyboard in Gnome 3

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.

46 thoughts on “Introducing; Maliit on-screen keyboard in Gnome 3”

  1. Good to see a nice virtual keyboard in the linux desktop too!
    This video also shows how far we actually are from having a usable touchscreen UI in the linux desktop: integration with the VK, scrollbars, widget sizes… 🙁 But a VK is the first step, and in this case looks like we are starting with the right foot! 🙂

  2. Is it possible to run this program in the mode, where the keys are circle shaped? I theorise, that because of the circle nature of the finger tips, navigating towards circle shaped keys would make it easier to type on screen, without the need of a physical keyboard. Also, this woulc cause the aiming to be more easier, giving the user clear boundries where the hit zone actually is.

  3. Having keys that are visually circular would be very easy, this can be done simply by changing the graphical assets of the theme (in an SVG file)!
    As far as hit zones, things are more complicated. The actual hit zones of the keyboard are actually bigger than the visual indication of each key; the “reative area” also includes the margins of the keys. This is an established best-practices for on-screen keyboards, especially on smaller form factors like handsets, as it gives better typing speeds. This is one of the things I hope we will have blogposts about soon (as mentioned in the post)

  4. You are so right. I indeed believe that this would be the right foot to start with. However, some people in Gnome seem to want to invent their own keyboard instead of using Maliit, which I think is effectively a step back.

  5. Youtube requires Flash or WebM support, which might not be available out of the box in F14. I will try to upload a ogg/vorbis/theora video for those who cannot or will not use youtube.

  6. Yeah, a tablet spin would be nice. I do not think I/we have the time to create and maintain a tablet spin right now, but once we have packages we will definitely help people doing it.
    The WeTab can only be purchased in Germany, unfortunately. It uses a reference design from Intel, so you an essentially get the same tablet from other manufacturers. I believe that the ExoPc is available in the US, for instance.

  7. Looks nice, although It should either overlay that maximized window, or restore the size when going away.

  8. Dear Jon

    If defining the shape the keys take is so easy, why not offer the Round Keys as a Pre-set? I mean, if it’s as easy as you say it is, it shouldn’t take you that long to create! Of course, although this might not be as efficent as the round rect keys, at least you’d be giving the users the choice to use round keys if they so wish!

  9. Is there a way to expand automatically the keyboard to the screen width ?
    It would be also cool to have some kind of automatic overlay (like on smartphones) once we hit a text-editable zone (thus you will not have to resize the window afterwards).

  10. Wow, that would be really good, although Gnome have alot in Shell interface and many programs wouldn’t be really usable the way they currently are.
    Question, couldn’t therer be a smart input that would write the most possible word while you write? I know that OpenOffice has this feature, but I’ve only seen it there….

  11. Smart input as you say is possible, one just needs to plug in an error correction/prediction engine. There is no FOSS implementation of that at the moment, but this would be pretty easy to do. One could for instance then use the same engine that OpenOffice uses, just wrap it to fit our interface.

  12. Nice looking KB with some great features. You should get it added to that Gnome OSK page you link to as a reference implementation for them to look at rather than reinventing the wheel.

    I wonder if this keyboard could be run as part of the Gnome 3 notification area. Those pop-ups seem to float over the active window rather than displacing them and are easily dismiss-able/ignored if you accidentally tapped on a text entry field. The OSK coming up when I don’t want it to (for instance when a webpage first loads and forces the cursor to a text field) is likely the biggest annoyance with my tablet OSK.

  13. Fantastic start! But why did you choose to resize the window instead of making the keyboard an “AlwaysOnTop” window?

  14. @Leo, Stéphane:
    As requested, three variations on the theme.

    1. Maliit with circular keys, done by changing the graphical assets in SVG and border values in CSS: http://taschenorakel.de/pictures/meego-input-methods/2011/05/01/gnome-shell-circles.png

    2. Maliit with auto-layouting where keys grow to consume full desktop width. Done by changing the MeeGo Touch target profile to fit the WeTab’s screen resolution and by enabling auto-layouting in CSS (“use-fixed-key-width: false;” for all keyboard layouts): http://taschenorakel.de/pictures/meego-input-methods/2011/05/01/gnome-shell-extend-keys-over-entire-area.png

    3. Maliit with pixel-perfect layouting but keyboard background consuming full desktop width. Done by increasing padding-left, padding-right in the CSS: http://taschenorakel.de/pictures/meego-input-methods/2011/05/01/gnome-shell-full-keyareabg.png

  15. @mikhas

    Will these themes be intalled by default with the Maliit package, or will these themes need to be downloaded separatelly? My gut says that these themes should be added by default, if they’re just SVG file variations on the theme, causing the theme defining file to be rather small

  16. @Leo: given that our background is MeeGo, customization is an important feature for us. The price for that is rather complex semantics, as can be seen by the crowded CSS file (http://meego.gitorious.org/meegotouch/meegotouch-inputmethodkeyboard/blobs/master/m-keyboard/theme/libmeego-keyboard.css).

    For MeeGo 1.3 for example we plan to restructure our packages a bit to ease customization even further.

    I would expect that every device (and every platform !MeeGo) would get its own theming anyway, and that the communities provides plenty of theme variations so that it never gets boring 😉

    In the end though my focus is on improving usability, and whilst we reached a good usability on handsets already (also due to tight integration with the MeeGo Touch Framework), we are far away from that quality on tablets, to be quite honest.

    Our theming capabilities are nevertheless good, but new ideas need to fit our concepts of usability.

  17. When would this been available to download? Maliit is my favourite keyboard to use on a tablet and can’t wait to use it in Fedora 15.

  18. It looks nice, but that video doesn’t show Maliit on the gnome-shell overview.

    About the comment “some people in Gnome seem to want to invent their own keyboard instead of using Maliit, which I think is effectively a step back.” I guess that you are talking about the conversations on this bug:

    https://bugzilla.gnome.org/show_bug.cgi?id=612662

    FWIW, “invent” a new OSK from scratch was not proposed. It was proposed re-use existing OSK like eekboard or Caribou.

  19. @API. I saw other OSKs proposed as well (the whiteboard page has more), but it still seemed to me the shell developers wanted their own own solution. Maybe I read the situation wrong.

  20. Itching to get my hands on the Fedora packages for Maliit!! Any updates on when it will be available?

    Also can you change the settings in order to make the keyboard overlay other applications since I don’t really have the screen space to resize the window in order to fit the keyboard on as well. In MeeGo I could always swipe down the keyboard to hide it if it was blocking my view.

  21. Ollie: We hope that Fedora packages will be available in the next couple of weeks.

    For the keyboard to overlay applications is the default behavior. The video showns some experimental window relocation feature I did. I did not mention it in the post because at the time it did not work too well (no undo when keyboard is minimized).

  22. I have install Fedora 15 x86_64 w/ Gnome Shell on my tablet, but can’t get the Maliit keyboard to start.
    I’ve installed Maliit as described under Fedora on this page: http://wiki.meego.com/Maliit/Installing.I think it went well.
    I’ve tried to create the file /etc/xdg/autostart/meego-im-uiserver.desktop as mentored in the link above under MeeGo and added both “export QT_IM_MODULE=MInputContext” and “export GTK_IM_MODULE=MInputContext” to ~/.bashrc but I can’t start the keyboard.

    It would be super nice if someone could help the so I can use the keyboard 🙂

  23. @Louis: My blog is not the support channel for Maliit, use our communication channels as described on the main wikipage if your problems continue. Note that the GTK+ inputcontext is called meego-im, not MInputContext so have to do “export GTK_IM_MODULE=meego-im”. Also note that the .desktop file from Meego cannot be used on Fedora (it contains OnlyShowIn=X-MEEGO-HS;X-MEEGO-NB). Please start the uiserver and the application in a terminal to verify that it is working before trying to do autostarting et.c. Integration packages for Fedora that will make this just-work(TM) will be provided soon-ish.

  24. sooo, any news yet?
    your “test version” basicly works but i havnt figured out how to automaticly popup the keyboard or even manualy start it without adding a a programm to start in shell manualy

  25. Where do we get ARM packages for Ubuntu? I would like to install in an Ubuntu Chroot on the HP TouchPad, probably in LXDE.

  26. I am not aware of any pre-build Ubuntu packages for ARM, and I don’t think that we will provide them in the foreseeable future.
    The code is portable, and known to run on ARM (Nokia N950/N9), so you could use the existing debian meta-data as a base for creating such packages.

Leave a Reply

Your email address will not be published. Required fields are marked *