Maliit Status Update

We’ve been busy! The result is our latest release, Maliit 0.99, with a massive amount of changes. While the framework has mostly seen code cleanups (:~/source/maliit/fw$ git diff 0.94.0..0.99.0 --stat: 389 files changed, 3612 insertions(+), 30081 deletions(-)), we’ve been adding tons of features to the reference plugins (:~/source/maliit/plugins$ git diff 0.94.0..0.99.0 --stat: 324 files changed, 32499 insertions(+), 12799 deletions(-)).

After (finally!) getting official Debian and Ubuntu packages, the next big step is our Maliit 1.0 release, which we expect sometime later this year.

Maliit 0.99 works with applications using GTK+2/3 or Qt4/5, though Qt4 still works best. Maliit’s framework and reference plugins strictly require Qt5 as build dependency, allowing us to get rid of Qt4 and Xlib legacy code. Maliit can run on Wayland but at this point only EFL applications support Wayland input methods. For Qt5 applications wanting to use Maliit together with Wayland, a Qt5 platform plugin for Wayland input methods would be needed.

Who is using Maliit?

The best Maliit showcase is still the Nokia N9. No other device got anywhere near to the demonstrated input method integration level. The haptic feedback of its virtual keyboard remains unchallenged. I think it’s a major success for our old Harmattan text input method team that we see Maliit being used in other projects. It was hard work to get to this point and yet it feels as if this was only the beginning of Maliit as an open-source project.

We have the friendly folks beind the OLPC project who were one of the first to go with Maliit. Few of us will probably make the new XO their primary device and therefore, won’t see the results of the collaboration. But from the very beginning, they worked with us in the open, provided official Fedora packages and helped us test-driving the then-new styling engine of Maliit Keyboard. The XO is one of the use-cases where Maliit has to run without a compositing window manager, which made them an early adopter of our windowed mode.

Plasma Active is another project that — for its size — invested significant development time improving and testing Maliit’s reference plugins. They’ve been (and hopefully remain!) a huge help whenever we faced problems with QML. I wish we could find a sponsor however to work on improving their input method integration, which is the “invisible” and challenging part that easily gets forgotten.

Ubuntu Touch is choosing Maliit as well. Canonical sponsored significant work in Maliit Keyboard, especially in terms of Qt5 support and replacing QGraphicsView with QtQuick2.

SailfishOS is happy user of Maliit, too. They are the main consumers of our 0.80 branches that still offer full support for Qt4 and X11. We always considered 0.80 our latest “stable” release branch, so it’s good to know that at least someone is also using it.

OpenEmbedded has integrated Maliit into their meta layer. This makes it easier to build custom Linux distros for embedded with Maliit on board. My understanding of OpenEmbedded is still limited at this point so I cannot explain all the real benefits this collaboration provides. Luckily there’s the always friendly Samuel Stritzel who’s following our official mailing list, waiting to answer all your OpenEmbedded related questions.

Gnome3. Just kidding. But once Gnome3 properly integrates with Wayland input methods, we can just plug in Maliit, too. Of course to be of any interest for Gnome3, we need to demonstrate working CJK input methods too. Luckily, we got the opportunity to just do that: IBus working with Wayland input methods. If things pan out I’ll be talking about this at GNOME.Asia.

I would like to get the chance to improve input method support for Firefox and Chrome/Chromium. There is one nasty bug around password fields that’s been quite a blocker for us. Some day, we’ll hopefully be able to convince the browser guys to just “do the right thing”.

And then there’s yours project of course. You just didn’t tell me about it yet ;–)

Architecture

There is an influx of new developers showing interest in Maliit which is why I feel that reiterating the basic architecture behind Maliit doesn’t hurt.

Maliit is split into three parts: framework, reference plugins and input method modules (GTK+, Qt4, Qt5).

The framework provides maliit-server, a process that can load reference plugins (such as VKBs) and allows applications to connect to it through input method modules. The input method modules are UI toolkit specific and are loaded dynamically by the applications. For each UI toolkit Maliit wishes to support, a separate input method module is required.

Input method modules and framework are designed as client-server architecture, with applications behaving as clients. The default IPC is QDBus but it can be replaced by other mechanisms, for instance the Wayland IPC.

In a follow-up blog post I will provide an outlook of where Maliit goes next and which parts of it we might have to rethink, now that the leviathan of Linux DEs is quickly moving towards Wayland.

People

Those are the people who have contributed to Maliit, but you wouldn’t know if you only checked commit messages:

• Łukasz Zemczak, Thomas Möricke and Kevin Wright: You guys have been great. Would work together again.
• Iain Lane, Michał Zajac, Peter Robinson: Without you, we still wouldn’t have proper Debian/(K)Ubuntu/Fedora packaging. Thanks!
• Samuel Stritzel: Thanks for bringing Maliit to OpenEmbedded! Hopefully we’ll see more use of your work soon.
• Simon Schampijer, Daniel Drake, Gary Martin, Jennifer Amaya and Martin Langhoff: Thanks for the opportunity to work on OLPC. I know most of us are not in the target audience which makes it hard for you guys to motivate others to help you. Your work is important, please never give up.
• Pekka Vuorela: I am just glad to have you back in the team. Maliit just isn’t the same without you.
• Aaron Seigo, Marco Martin: Thanks for all your enthusiasm about Maliit and Plasma Active. Your motivation is infectious.
• Jan Arne Petersen, Krzesimir Nowak: I am impressed by your motivation and dedication that you still have for input methods, even though none of us ever planned to become an “input method expert”.

FOSDEM 2013

I am back from FOSDEM and I am always surprised how quickly it’s all over. Would you believe that I only got to attend two talks again, one of them being my own about Wayland input methods?

Friday Feb 1st

I arrived Friday evening, this time by train. Since I bought my first BahnCard ever in August last year, I am slowly convinced now that flying is just a huge waste of time and should be the last possibility to consider, not the first. Even though I spend much more time on the train than I would on the airplane I still travel more relaxed. Others claim to be super-productive on trains. I am happy enough if I get to braindump my thoughts into my notebook (the dead-tree variant) and then read a book (more dead-tree) to forget about work for once.

Another trick for better conferencing is to arrive (or leave) 1-2 days earlier (later), as this helps catching up with sleep and allows to process thoughts or just do some random stuff not related to conferencing, say, going to a museum or gallery. It allows me to be reckless to myself during the conference without needing one week to recover.

But back to that Friday evening: I was very happy that Quim could make it to our dinner at the Kabash. I knew he had a busy schedule for the next days and that I probably wouldn’t be able to meet him in Berlin. I think he enjoys working for Wikimedia even though he now has to pay for phone calls and 3G. We also had people from Igalia, Digia and Intel OTC joining. We enjoyed great food and nice conversations, then headed off to the beer event. This one has become crazily crowded. It’s nigh impossible to find people you know. Meeting new people is also a challenge. The entire concept of what should be a simple meet&greet is lost these days.

Saturday Feb 2nd

Jens and I arrived around 10am at the campus on Saturday, probably a first for both of us to be so early. It was so empty you could think they’d cancelled FOSDEM but that quickly changed of course. I had zero slides done by then and no motivation to do them either. I went to Dave’s talk and it was nice to see him and Mardy working on a relevant project again. As expected, GOA is dead in the water by now and work will most likely continue with accounts-sso. I realized that I would have to recycle an older talk for some slides, something I loathe to do.

Somewhere in between I had to meet some OpenEmbedded guys to debug Maliit on their custom hardware, but we didn’t get much further than realizing that dlopen() didn’t work properly.

Funniest thing that happened that Saturday was probably rasterman, timj and thiago trashing-talking about the kernel when they could have told each other how much their toolkits suck!

Biggest reveal of the day, however, was that Rob Taylor toured with the Darkness in his crazier years.

Jens was unlucky with his hands-on DLNA talk, but I blame it on the room (Lameere). I remember that my talk there last year was crap, too. None of his prepared demos worked and people started to leave the room. I felt bad for him because I the was one who pushed him into giving the talk. Mark took over the second half and surprisingly, all of his dLeyna demos worked. He got applause (and rightfully so) for each of them.

I only had two hours left by then for my talk (slides). Meeting more people all the time didn’t exactly help with my preparations. I was close to call Luc (organizer of the Xorg DevRoom) and ask him to cancel my talk. I am glad I didn’t because it turned out that worrying about my talk for the whole day was the best way to get back into the topic. You have to understand that Wayland input methods is a yesteryears project for me, all the hard thoughtwork as been done already and I have been mostly working on new projects since August last year. I think the talk was well received by the audience (at least the room was packed). However, I cheated by simplifying and ignoring the actual complexity of input methods a bit.

It was already getting late and by the time we arrived in Brussels center it was about time to head to the Gnome party. Same place at last year, but by around 11pm we had occupied the whole building. I didn’t even know half the guys. Gut feeling tells me this is a side effect of the UX hackfest that happend before, but I would like to believe that the Gnome community is growing again. It was great to see Gnome legends such as Federico or Alp attending, I think both of whom I had last (and first) seen in 2008.

Sunday Feb 3rd

I thought I’d be able to attend a couple of talks on Sunday, but I got stuck talking to people interested in actually working open-source DLNA stacks. I got invited to join the Xorg dinner in the evening, with half of the people being BSD guys. Xorg? BSD? I was fearing for my sanity. Some other embarassment might better be left unmentioned in this blog but the food and wine at least was great! Afterwards we ended up at Delirium again (where else …). At 2am we had to move to the Absinthe bar right next to Delirum. Wiser men than me (such as krh and Rob Clark, who now works for Red Hat!) left before, however. And so we ended up with more beer and several shots of Absinthe until the wee morning hours. Jon made the mistake at that point to ask me about my honest opinion (I actually don’t know why he tagged along with the Xorg hackers for so long), he might regret that by now. Wrong time, wrong place. Happens.

Monday Feb 4th

I had to checkout at 11am and get my train at 2:30pm. How I managed to get up by 11:15am I still don’t know. But luckily I was able to meet with Kat, Dave, Martin & Tobias for some waffle & chocolate breakfast. This was a much better FOSDEM ending than last year.

Tobias chose the same ICE train as me. Poor him, he had no idea what was coming for him: He had to endure my satirical reality talk from Brussels to Cologne. Both of us had to change trains then, with him heading off to Hamburg and me returning to Berlin. I wish I could have made it back a couple hours earlier now because I missed Quim’s presentation in the Wikimedia office.

Exhausted but happy, I finally arrived at home on Monday night.

Concrete problems and generic solutions

For the official Gnome3 virtual keyboard, one can notice how the space bar is strangely sized, how the regular keys are unpleasantly square and how the enter and backspace keys are way too small. They all use the same graphical asset. For the Gnome3 styled Maliit Keyboad, the letters d-j, x-n, together with the space bar and its neighboring keys, form a neatly aligned center area, with a staircase pattern to each side of the keyboard. If you look in the last row, you will notice that the space bar is just a few pixels too large. This happens because the only non-pixel-perfect elements in the Maliit Keyboard are stretched keys and spacer elements, and I somehow still compute their width incorrectly. From a designer perspective, that “pixel bug” in the layout destroys the immersion of an otherwise good design. Pixel perfectness — whilst having a poor reputation among us developers perhaps — is actually quite a challenge to get right!

Maliit Keyboard is a reimplementation of the MeeGo Keyboard that was shipped on the Nokia N9. It doesn’t share any code with it, but it does reuse the ideas and the XML layout files. The format for the layout files evolved from programmer-friendly to designer-friendly over time, which I think was a good change. Instead of using the complex and pretty generic styling system of libmeegotouch (which was intended to fit the needs of any mobile application), I use a concrete style class that reads a styling profile folder, looks into into the two INI files (one for the main keyboard area, one for the extended keys) and fills a model with style attributes. In the given context of virtual keyboard styling, the concrete solution offers the same flexibility as the generic solution but comes with a fraction of the implementation complexity and remains simple to extend. This is because the concrete solution fits the intended use-case perfectly, whereas a generic solution will always acrue overhead.

The trade-off, of course, is that for a new use-case, I’d probably have to write a new style class and create new style attributes. It is very unlikely, however, that the styling requirements of a fairly specific “application” would fit the the styling requirements of a regular application, so why burden myself with a generic enough abstraction that I will never use? Inversely, why try to make a generic solution fit a specialised problem? Jokingly, that’s precisely what I call Java programming: Instead of solving the problem at hand, write a framework that can solve all similar problems. I have started to grow a strong aversion against that, not because I like reinventing the wheel (I don’t), but because I think that understanding the concepts behind an idea is far more valuable than clinching to an implementation of it.

For the Maliit Keyboard, I took the concepts of the libmeegotouch styling system and mixed my understanding of CSS with the XML layout files. The result feels pretty clean and easy to use, but that’s because I based the implementation on well-understood concepts, not because of the implementation itself. Who knows, if I keep myself busy with implementing virtual keyboards for just a bit longer, I should eventually be able to write a pretty decent book about VKB design patterns ;–)

Trip to California, May 2012

In anticipation of two busy conferences in the San Francisco Bay Area, the TiZen Developer Conference 2012 and the Ubuntu Developer Summit for the Quetzal release, I prepared myself by arriving one week earlier. This avoids the stress of a long distance flight immediately before conferences start, but also helps to adjust yourself to the environment (e.g., get used to public transport, find your ways around the area, get used to the food, etc.).

(download)

Click here to download:

trip-to-california-may-2012-jqeJwfDcvCHniBycbIue.zip (21.99 MB)

My flight to California was somewhat jinxed. Instead of getting a direct flight to SFO from an European airport, I had to change over in Miami. So instead of 12 flight hours, I was already up to 17 hours. Then the flight got delayed, and I of course missed the connection flight. Being rescheduled to the next flight meant another 5 hours of extra waiting time and arriving at SFO briefly before midnight. Which means no public transport for you. Luckily, I had informed Quim Gil about my additional delays (thanks to free WiFi at Miami airport), and being the good friend that he is, he decided to pick me up from SFO.

On the next day (a warm Sunday), I had time to visit the Computer History Museam in Mountain View. Later that evening, Quim, Henri and I met for a few drinks, the outcome being this Maemo thread. Sadly, the thread itself has seemingly no positive outcome yet.

On Monday, it was time to go to San Francisco, where I spent the next days (mostly) working and preparing my TiZen session for next week. It was great to experience San Francisco from a non-tourist point of view (though I still had to visit Johnny Rockets together with Alberto, Łukasz, Kat and Dave, the milkshakes really are that good). My highlight of the week was perhaps the lunch with the ever friendly Yorba guys on Friday. I saw their awesome new T-shirts, but sadly they’re for employees-only.

On the weekend, I met with Lokesh and we drove down to Santa Cruz (great beach, lots of surfers, too) and from there to Monterey, on the famous 17-Mile Drive. I even dared to (very briefly!) swim in the Pacific Ocean, another first for me. The Pacific made me pay my courage in blood though (nothing too bad, just an annoying cut at my heel).

Then, well rested and all that, it was time for the conferences. Since there was only one keynote for Monday evening at the TiZen Developer Conference, I spent most of the day at UDS. The one thing to notice was probably that UDS had way more developers than TiZen, and to my surprise, even some high profile GNOME developers attended UDS. So much for all the silly fights about Ubuntu not being GNOME etc. I also met Daniel d'Andrader again, which was nice.

For the other two days, it was always a bit of back-and-forth between UDS and TiZen. UDS had the better food (breakfast, hm!), but TiZen probably had the better parties (California Academy of Science comes to mind). On Thursday I started to feel exhausted and on Friday, I was glad UDS was to be over soon. The beach party (without a beach) totally killed it.

The flight back was uneventful. After two weeks in California, with the second one being extremely stressful, I was glad to finally land in Berlin again.

TiZen Developer Conference 2012

The first day started slowly, with only one keynote in the evening. I wasn’t very happy with it, a proper keynote would have focused more on the visions and goals of TiZen, not so much on Linux or Android, or Microsoft.

On the second day, my mind was mostly occupied with my own session, “Challenges of mobile text input”, in the afternoon. It was good that speakers were informed early enough about the whole process, and the presentation templates were available long enough before the event. Even with the cold color scheme, I kind of like the clean TiZen design in the templates (though I still can’t get used to the name “Ti-Zen”).

Two hours or so before my session, I had one technician help me upload my slides to the room’s PC. It’s great to not have to use your own laptop. Instead of worrying until the last minute whether everything will work, you know it just will, and if it doesn’t, it is not your task to fix it. Not having this typical presenter’s crisis helps to focus on the content of your session and also helps to stay calm.

I was quite happy with my presentation, even though I was hoping for more input method developers in the audience. You can find the slides on the Maliit wiki, video (or at least audio) should be available at some later point, too.

On the last day, every attendee could get a TiZen developer device. I was surprised it didn’t have “Intel Inside”, but the ARM Cortex9 with the Mali GPU is interesting hardware nevertheless. Perhaps not too surprising for a HTML5 platform, it also comes with a speedy and actually useful mobile browser from the start. Even if it is uncertain at this point whether TiZen will end being a success, I am looking forward to see actual TiZen consumer devices.

Thanks to the Linux Foundation for sponsoring me, and thanks to Brian Warner again for helping with the organising bits.

The challenges of mobile text input

I am going to speak about mobile text input at the TiZen Developer Conference (7-9 May, San Francisco, CA). My session is scheduled for Tuesday afternoon (PDF).

I had planned to only focus on the technical aspects, but I am also going to talk about other aspects, such as the media coverage a cleverly designed text input method can achieve, and which features are apparently important to consumers.

The most important feature is, unsurprisingly perhaps, the overall performance: How fast can consumers insert or manipulate text on their mobile devices — while still being accurate? I will explain techniques that can help to improve responsiveness, accuracy and speed of a virtual keyboard.

I’ll be in the bay area until end of next week and I am generally interested to discuss the finer details of (text) input methods, accessibility or display servers and how one could improve the situation for accessibility on Linux. Contact me on Twitter in case you want to meet up and go somewhere for dinner (or drinks) in the beautiful city of San Francisco!

Maliit Keyboard now with word prediction and error correction (video)

This is a feature that I personally wanted for a long time. Interrupted by FOSDEM, some Wayland research and many other things, I finally managed to get word prediction and error correction beyond prototype quality. The video shows just how amazingly good the Presage word prediction can be, even without extensive training (in fact, for the video we used the minimal language model training that comes with a regular Presage installation). The second part of the video shows how combining Presage with a spellchecker such as Hunspell further improves the provided word candidates.

Presage uses a very scalable approach called text n-grams. There is a lot of research in that area, but language models of contemporary language usage are either well guarded or cannot be freely distributed. Luckily, Presage comes with training tools such as text2ngram. Users can feed arbitrary language corpora to it, though one should be careful to perhaps not mix different languages too much.

Matteo Vescovi, the author of Presage (formerly known as Soothsayer), started the work as part of his master thesis a couple of years ago. The heart of Presage are the different predictors. They can be queried in parallel and the result lists are merged, using probability analysis.

Presage certainly has a lot of potential. It comes with an easy to use C++ API but also provides bindings for C and Python. In fact, it even provides a D-Bus API, which would make it possible to run it as a system service. The user could then benefit from (and train!) the same language models from different applications.

Hunspell probably doesn’t need much introduction. It is used in many Linux desktops. It’s a fine library and comes with many dictionaries. However, one should be aware that Hunspell itself cannot provide word prediction, which is why it wasn’t enough for mobile text input. As a fallback for Presage, it works very well though.

Of course there are a couple of things we could do from here. As Jon mentioned in the video, the virtual keyboard’s word ribbon UI could host word suggestions from other applications, such as the Google search in the browser. For Unity’s dasher input or Gnome Shell’s search, the application names could be shown instead. Or we could hook it up to Bash completion.

PS: Anyone up to package Presage for Fremantle or Nemo? It could be pretty interesting to see the next release of Maliit running on the N900.

Designing an input method system for Wayland

As mentioned before, Jon and I met with Kristian Høgsberg and Peter Hutterer during FOSDEM 2012. The discussion quickly revolved around Wayland and input methods. Kristian and I basically picked up from where we left after the Qt Contributor Summit last year in Berlin.

Right now, there is no explicit input method support in Wayland, and it’s the responsibility of the applications to provide such. But we came to the conclusion that moving it into Wayland provides several benefits.

That is why I spent some time during February to write down an initial design proposal, using the two years of experience from working in the application framework team for the Nokia N9. It has gotten longer than expected, but hopefully it is structured well enough to still be accessible.

From the introduction:

Currently, Wayland has no explicit text input method support and relies entirely on toolkit-specific or platform-specific solutions. This is awkward for platforms that support multiple toolkits. The resulting fragmentation and re-implementation would make it hard to attract developers of high-quality text input methods. These developers would generally prefer a unified architecture that lets them ignore application-specific or platform-specific details. This would let them simultaneously target all platforms that support Wayland.

We believe this goal can be reached by adding two new Wayland protocols, of which only one requires adaptation by toolkit providers.

The idea is not new, XIM has been around since the dawn of time. Because of the protocol’s daunting complexity, it apparently never became popular among application toolkit providers. That is why I decided to split up the envisioned Wayland input method protocol up into two:

• The Wayland text protocol, to be used between the Wayland compositor and its clients. It tries to keep input method knowledge to a minimum and therefore can be used for any kind of (hardware) input that results in text input.
• The Wayland input method protocol, to be used between the Wayland compositor and the input method system, which can either run as a stand-alone process or inside the compositor process.

In the proposal, I explain my ideal solution where applications and input method system are completely separated from each other and where the compositor acts as a mediator between them. I continue with alternative solutions that are feasible but have several drawbacks. Towards the end, there is a comparison matrix that features all discussed solutions.

There is an important aspect though: The alternative solutions provide an iterative implementation approach to reach the ideal solution. The obvious idea here is that already in early stages, we get testable prototypes. The solutions with a compositor-hosted input method system for instance allow others to think about window management policies that take input methods into account, whereas I could continue my iterations towards the ideal solution.

Anyhow, the next steps are now to discuss the proposal in a wider public (feedback from developers of exotic input methods especially welcome!), possibly also at upcoming conferences, and to come up with a prototype implementation so that we can iron out protocol bugs.

I would probably target Qt 5 as the first application toolkit to support the Wayland text protocol, followed by GTK+ and perhaps Enlightment. One also needs to take the popular desktop shells into account, such as Gnome Shell, Unity and Plasma Active.

Maliit could fill the role of a reference input method system, but we should have at least one more implementation, at some stage (IBus comes to mind, naturally).

Looks as if this could keep me busy for the better part of 2012, but it would be great if we could get at least the Wayland text protocol into Wayland 1.0. It’ll require some luck though.

Maliit as your remote control (video)

There is seemingly a trend (in ideas) to use your mobile device as a remote control for stationary devices such as your TV.

We thought that experimental support for remote text input should be easy to add to Maliit, as it already comes with a server-client architecture. As soon as client and server can run on different host machines, we’d have network transparency and it should basically just work. Luckily, we use D-Bus as our IPC, and it turns out that D-Bus understands remote host addresses. If you check the README in maliit-framework you will recognize that – with the latest release (0.90.0) – it only takes an additional environment variable, MALIIT_SERVER_ADDRESS, to connect a client (that is, an application that uses the Maliit input context) to the input method server. The scary part is perhaps that one has to disable D-Bus authentication. Therefore it's a good idea to only use this inside a trusted network.

Jon created a video which demonstrates the new feature in a better way, using a laptop that is connected to a projector as a TV replacement. The great thing about this feature is that it requires no changes to the applications, nor to the Maliit input method plug-ins, it’s the framework that handles this internally (or not so internally, now that Qt 5 turned our D-Bus API into a public one).

However, to make Maliit truly useful as a remote control, at least two additional features are required:

• Have a proxy text editor widget on mobile device that allows text interactions such as copy and paste, cursor positioning and rich text formatting.
• Emulate and transmit mouse or touch events, possibly through a dedicated touch area on the touch screen of the mobile device.

The second feature requires an extension to the Maliit protocol, whereas the first is already filed as bug MALIIT#84. After that, I could use my N9 (or my N900, as Maliit also runs there) to remote control my Gnome or Ubuntu Unity desktop, which would work perfectly for my movie watching habits. Kudos goes to Krzesimir and Jon for their work on this feature.

FOSDEM 2012

FOSDEM in 2012 was an exciting (and naturally, exhaustive) conference again. It's great to have so many relevant people who are all active in the free software world together in one place. It's also a great opportunity to discuss radical new ideas, ideally while experimenting with Belgium beer. Which is what we usually did when we weren't at the conference site.

It was nice to see Jarno and Esko at the conference, too. We even stayed in the same hotel. I hope they enjoyed the Ethiopian lunch as much as I did. And perhaps they're not too angry any more that we lead them to drink Absinthe ;-)

Jon and I gave two talks. Jon's talk (slides) was about Maliit as a project, explaining what Maliit is (and what it is not), combined with a short history lesson about the project. I tried to outline the difficulties of mobile text input in general (slides), picking some use-cases that are known from the desktop world and showing why simply copying the use-cases and their known interaction models does not work very well. I honestly liked Jon's talk more though.

Neither of us two actually managed to visit other talks, even though we wanted to. We had to ask Jarno, Esko and others about what great talks we missed. Apparently there were quite a few :-(

Our Maliit T-Shirts were well received, though we usually only handed them out when someone listened to our Maliit ramblings long enough.

We were asked about accessibility several times, which is currently not within the scope of Maliit but perhaps something to think about in the future.

We also got to talk with the people working on (text) input in Redhat and Intel, mostly in the context of Wayland. There are some interesting opportunities to get things (more) right this time around.

Thanks to our employer, Openismus, for sending us there!