Tag Archives: Qt

More Maliit Keyboard Improvements: QtQuick2

A few days ago I pushed 44 more commits to the Maliit Plugins repository now that Canonical have published (in the Ubuntu Phablet project’s maliit-plugins Launchpad/Bazaar repository) that work that we (Openismus) did for them.

This brings the Maliit Keyboard into the QML/QtQuick2 world for Qt5, removing the use of QGraphicsView which is not really suitable for Qt5. This should also have some performance advantages and makes customization even easier.

Michael Hasselmann blogged a summary of the state of Maliit today. The recent work, along with the Wayland integration, has made Maliit more popular than ever.  But we still need to line up customers to fund the ongoing development, generally while creating custom features or solutions for them.

Maliit Keyboard Improvements

On Friday I pushed 194 commits to the Maliit Plugins repository, adding new features, bugfixes, cleanups and tests to the Maliit Keyboard. This is some of the work Openismus has done for Canonical over the last few months which we are now allowed to upstream. This includes hard work by Michael Hasselmann, Krzesimir Nowak, Jan Arne Petersen and Jon Nordby.

Our work on the underlying Maliit Framework for Canonical was published upstream as we did it. We believe we’ll be able to upstream more of our Maliit Plugins work in the future.

Versions of these Maliit Plugins commits were published a few days ago in the Ubuntu Phablet project’s maliit-plugins Launchpad/Bazaar repository. It also contains commits (not by us) on maliit-plugins’ Nemo Keyboard, mostly for integration with the Ubuntu Touch platform (and its use of Android’s Surface Flinger). The recent Ubuntu Touch preview is using a version of that Nemo Keyboard, though we believe that’s meant as a temporary solution. A properly integrated Maliit Keyboard should behave significantly better.

Anyway, these commits add these features to the Maliit Keyboard:

  • Auto-capitalization.
  • Styling, such as a black underline for the current word and a red underline for a word with an error, though its up to the toolkit exactly how it shows this.
  • Word prediction, error correction, etc are now available when editing previously-entered words, instead of just the next word, taking into account the surrounding words.
  • Users can add words to the dictionary with a long press on the space key.
  • More settings to enable/disable auto-capitalization, auto-correction, word prediction, error correction, audio feedback and whether the word ribbon should be disabled in portrait mode.
  • Applications can specify text and icons for actions keys, such as Done, Go, Login, etc.
  • Keyboard themes can now specify fonts.

The maliit-plugins NEWS file gives more details.

Many of these features were already in the old MeeGo Keyboard (used by the Nokia N9) which had to be dropped last year because of its libmeegotouch dependency and its need for proprietary plugins to achieve these features.

We hope to have all this in an official Maliit release soon.

Programming For Kids

I tried a couple of applications with my four-year-old son: Pictomir and MIT’s Scratch.

Neither seem particularly well maintained and neither are suitable for young children without lots of supervision. Pictomir is easier to get started with, but not easy enough. Scratch is probably more interesting to older children, though they’ll partly be learning about how software is still so often arbitrarily annoying, and I’d prefer that they were introduced via a better example. I’m very tempted to write something better.

Pictomir

pictomir
Pictomir at first start up.

Pictomir leads the child through a series of levels, telling an R2D2 robot (Don’t tell George Lucas) to move around some isomorphic squares to paint some tiles. At the beginning the program exists and the child just needs to click the play button. In subsequent stages the child has to build part of the program himself, and then all of the program.

The available commands, at least at the start, are icons for left-turn, forwards, right-turn and paint at the top of the screen. These may be be dragged into the available boxes in the program at the right of the screen, though you can instead put them there by clicking to select and then clicking on the empty box in the program. However, the available commands are far away from the program where you must place them, so the child has to spend lots of time moving the mouse pointer back and forth across a wasteland of empty space.

I found an official Ubuntu package in the developer’s PPA. It was last updated to Ubuntu 10.10 (Maverick), but you can install it manually on later versions. All of its UI is in Russian, though you can ignore most of it because the UI is icon-based. When I built the newer code from source a few months ago, I think the UI was translated.

I guess that Pictomir was developed for a specific screen size and generally older PCs. It does not scale the playing area up, so the child has to deal with a tiny R2D2 on a tiny grid in the middle of wide empty space.

pictomir has a bare svn repository, though I can’t see how clean its commits are, and I don’t know if it’s still used. There are no commits since last year. My svn says that the svn format is too old to check it out, though I’ve checked it on on previous Ubuntu installations.

It’s website it quite awful (and only in Russian). I only discovered Pictomir thanks to commenters on Google+.

Scratch

The Scratch UI has several problems that make life hard for the child:

scratch
Scratch, after creating and running a small program.
  • Scratch requires the child to cope with tiny targets (See Fitt’s Law)
  • Scratch demands the use of drag and drop. This is frustrating for normal users, let alone children, and really hard with some laptop touchpads or trackpoints.
  • Update: Scratch requires the child to understand the difference between left-click and right-click. Right-click brings up a help context menu, which just causes confusion.
  • Update: The tiny commands have tiny text edit boxes. Children have a high chance of clicking it instead of clicking the command block itself. This problem could be partly solved by accepting drags on the edit box.
  • Scratch requires the child to double-click (see below).
  • The commands require the children to read, but a subset of the commands could instead be respresented by icons. The words are particularly hard for beginner readers because they are written in such a tiny font.
  • To get started with scratch, you need to figure out that you need to double-click on the first program command to actually start your program. There is no simple run button. You can cause your program to be run by clicking the green Flag button, but that’s something you need to put in your program.
  • When you try to move a command around in the program, it moves the command and all subsequent commands, as a group. So moving just one command means moving stuff around and then moving some of the stuff back to where you started.
  • Your program moves the Scratch cat sprite around the canvas, but that canvas is tiny, and the sprite can move off screen. The only way I found to get it back was to double-click the set-x-to and set-y-to program commands. I can figure that out, but beginners will not.
  • When you’ve drawn all over your canvas, the only way to wipe it is to go to the Pen set of commands and double-click the Clear command.
  • The sprite moves far too fast for the child to understand the relationship between the commands and the motion, without someone explaining it. If the command says move-10-steps then I’d expect the sprite to visibly move 10 steps. Advanced users might prefer it to be faster and smoother, but the default should make things obvious.

There are some other strange things in the UI which are probably a side-effect of its eccentric (Smalltalk) implementation.

  • Scratch has a menu (well, an icon-menu) for changing its language, instead of just using the user’s regular language.
  • None of the UI elements (menus, tabs, buttons, file chooser dialog, etc) match other standard applications on the system.

I think Scratch could be really popular with younger kids if it ran on Android with a touch interface and with less text, maybe as a simpler version. But the developers don’t seem to have any interest in that – they seem to be working on a Flash-based version of Scratch for the web, which is unlikely to work well with touchscreens, even if they can get Flash to work on Android and iPhone (they won’t). And I have no interest in hacking on Smalltalk. There seem to be various programming-language-based forks of at least the underlying engine, but none seem to be successful.

 

Openismus Revived

Here’s an update since my last status post in June.

Things have improved for Openismus even more though we are not complacent. Several proposals, including the ones I mentioned in that last blog post, have resulted in customer contracts. So we are now busy working on the Maliit input method system (virtual keyboard), Wayland, Rygel UPnP/DLNA and Evolution Data Server (EDS). We are even thinking of hiring another developer if we can find someone who is just right.

We are now established in the habit of creating proposals for customers, revising them, and shifting into implementation. We take our customer proposals seriously, making sure that the developers are the main authors and making sure that they don’t leave questions unanswered. If there’s something we might help your company with then we’d like the chance to convince you too.

Michael Hasselmann is now the main person negotiating new work for us and keeping some of that work on schedule. He has been very successful – a surprise to himself but not to us. We are calling him a Sales Engineer but that doesn’t really do his dedication justice.

Michael can travel much more than I could for the last few years. Right now he’s at the Automotive Linux Summit in the UK and tomorrow he will be at the X Developers Conference in Nürnberg with Jan Arne Petersen (where our interest is mostly in Wayland and input methods). On Monday and Tuesday he’ll visit me in the Munich office.

We have achieved this thanks, of course, to the hard work of our whole team at Openismus. They have fought hard so we can all keep doing worthwhile work that we enjoy. I am proud of them and glad to be part of this.

Openismus Status

As I mentioned in March, Openismus is now down to a small core of super developers.

Jon Nordby and Michael Hasselmann are now fully involved in finding new projects, and traveling when I cannot. This month we were relieved to get the go-ahead on projects for two new customers, for work on the Maliit on-screen keyboard. Those are our first new customers since Nokia disappeared. Hopefully we can talk about them soon.

However, this is still not enough work for us to feel particularly safe. So we have spent some time on open source work that we hope will attract attention by customers who want more of the same. Don’t hesitate to contact me if you’d like our help.

Openismus Getting Smaller

Openismus has recently had to let some great developers, and good friends, go. We are now much smaller.

This is really sad because it took us a long time to find and train these people, and they would be massive assets if the future looked better. Although they will be greatly missed, I am at least reassured that they will have no problem finding new jobs. I do hope that they don’t settle for work that is anything but worthy of their experience and enthusiasm.

This downsizing happened because we are now finally losing the customer work we had from Nokia, as expected since their February 11th 2011 decision to kill MeeGo. Nokia are not our only customer, but they are by far our largest. That gave us the opportunity to diversify, and we tried, but without much success. That failure is mine. On the one hand, it’s unfortunate that we have been so dependent on one customer. But, on the other hand, we would never have been so big for so long without them. I would do the same again without regrets.

I view the last few years of Openismus very positively:

  • We gave several young developers their first chance to prove themselves as professionals.
  • We trained new developers. They are now established as respected and experienced developers.
  • We made a few contributions to our favorite projects. For instance, natural layout in GTK+ 3.

Personally, Openismus has allowed me to work part-time, so I can spend time with my children. My first child was born soon after the company was founded, and for the first year, I worked from home, contrary to the myth that founding a company means working all hours of the day and neglecting your family. The tech industry is excessively male, with little understanding for men who want to share in the work of child-rearing, so I’m glad I had the freedom to work part-time. I am highly motivated to keep this freedom.

This has been a disadvantage, of course. For instance, I strongly suspect that I could win more customer work by traveling more to conferences and to customers on site. That has given good results when I’ve managed to do it. But this is simply an impossibility for someone who needs to take care of kids. I think the custom of business travel might be one of the greatest obstacle to women reaching top executive positions. It’s one of many things that won’t improve until men are forced to share more of the burden.

So, Openismus goes on, with some uncertainty. Our specific expertise in the Maliit input methods, in the QtContacts and EDS contacts systems, and in DLNA via Rygel should be very attractive, but time will tell. If you need help with GTK+ or Qt on Linux, from people who really know how, and are not afraid to tell you how, then we are still here and still ready.

 

Openismus at FOSDEM 2012

A few Openismus people will be at FOSDEM In Brussels this weekend. FOSDEM is always a great conference, but I can’t be there myself as my travel is generally limited by the need to take care of my kids.

Michael Hasselmann and Jon Nordby are both giving talks about the Maliit input method framework, as seen on the N9. We are eager to find customers who need our help to integrate and improve this only real choice for an open-source on-screen keyboard. So we hope that some people of influence take the opportunity to get to know the project and its excellent developers.

Jens Georg is also giving a talk about Rygel, used in the N9 to support UPnP and DLNA. For German speakers, there are already video and slides online of a recent talk that Jens did about Rygel in Berlin for Deutsche Telekom’s Developer Garden. I was amused to discover that DLNA had specified themselves into a situation where a minimum certified server and a minimum certified receiver were only able to share a small resolution JPEG format. Apparently it’s getting better, and Rygel can deal with it all.

Discussing Maliit Keyboards and Plasma Active

The Maliit developers and the Plasma Active developers, with some Mer developers too, discussed yesterday how they can work together. Reading the irc log, it seems to have been productive, with great input from all groups, and with some first development steps planned.

As always, I’m proud of our Maliit developers at Openismus. We believe that excellent developers must be communicators, or their work is for nothing. That log shows why.