Introducing KDE Games to fullscreen and touch interfaces @ Blue Wonder 2011

Two weeks ago I experimented with packaging the KDE Games for MeeGo and tried the results on the give-away Lenovo Ideapad from the MeeGo conference last november in Dublin with the MeeGo Netbook 1.1 installation. To find out that most games are quite usable even with only the touch-screen as input device, while some are not, but almost all are in desperate need for proper fullscreen support, for a full fun experience.

Remembering about the then upcoming KDE Games sprint Blue Wonder 2011 last weekend I quickly decided I should join this and start to do something about that (especially as Dresden is only a 2 h train ride away from Berlin and this also meant visiting my former home town and most fellows from the KDE developer community in Dresden). Thanks to Josef Spillner for being a host (and a good one) for me on that short notice πŸ™‚ Thanks also to my fellow workers Jon and Mathias at Openismus, they lent their Ideapads to me for the sprint.

While my plan was to work, for having a template, on my favourite game Palapeli, the really nice jigsaw puzzle game from Stefan Majewsky, I quickly was occupied with trying all the games, to gather some general information what works and what does not work. Do you know how many KDE games there are, only in the module kdegames? I did not, and was surprised about the number! That was my little blue wonder, and so I followed the sprint’s topic and may have played^Winvestigated all the games more than half a day in total πŸ™‚ (had to leave out ksirk and granatier for packaging problems)

So from my notes with regard to touch-screen input I found…
… these 15 games working out-of-the-box: Bovo, kdiamond, kfourinline, kigo, kiriki, kjumpingcube, klickety, klines, kmahjongg, konquest, kpat, kreversi, kshisen, ksquares, lskat.
They all only take either a LMB click (press&release at once) events on some coordinate or a LMB press, move, LMB release sequence as input. Which a tap or a swipe on the touchscreen is mapped to 1:1, besides by covering slightly more of the screen with the finger and the rest of the hand than the mouse cursor does.
… these 4 games working basically, but could gain from more support of touchscreens: kbreakout, kblackbox, killbots, ksudoku. The last three miss the highlighting of the rows/columns as triggered by hovering with the mouse, while kbreakout works but feels like that is only by accident. Beware: kbreakout will steal you more time than you planned to play it. It really works too well in fact πŸ™‚
… these other games to need work to be usable with a touchscreen:
Bomber, Granatier, Kapman, katomic, kbattleship, kgoldrunner, kmines, knetwalk, kolf, kollision, ksirk, ktron, ktuberling. What their (partially slight) problems are and how these could be approached will be hopefully topic of a future post.

With regard to making full use of the available screen, there was work to be done for almost all. Being developed along all the other work-oriented KDE programs it seemed obvious that for consistency they also get the usual menubar, the usual toolbar and the usual statusbar. Which all three steal much space in the vertical. Now are most screens more wide than high, while most games which are resembled by the KDE game programs have a rather quadratic form factor. The result: big unused spaces to the left and to the right, e.g. with KPatience:

Just see how much bigger the actual content gets if the window bar and the menu bar are removed:

The button to toggle between fullscreen and normal window you see in the toolbar in the screenshots is not part of the current program, I created an experimental patch to add this button to almost all games, which for now is only applied to the sources used to build the MeeGo packages of the KDE Games on the Public/Community MeeGo Build Service. I would like to improve this by having that button aligned to the right side of the toolbar, as it rather acts on a different level than the other buttons (I also wonder how much overlapping with the functionality of the windowmanager is here. What is the semantical difference between maximized window and fullscreen?).
Now imagine that toolbar also being disappeared, only sliding in on demand, e.g. by tapping on the upper boarder of the screen, like it is done to get the MeeGo Netbook 1.1 system bar. I think of something like Okular has when in presentation mode. The buttons of the toolbar could also be shown as overlays on a tap in some free space, if there is plenty of that in the game board. And then there are gestures, but those are yet to arrive in the Qt API IIRC, so not yet considered.

To have proper support for going fullscreen is especially needed for small-size form factors like netbooks and handhelds, with and without touch-input (but then even more, given your fingertip is quite large, unless you use a sharpener, well, don’t! πŸ˜‰ ). But also for bigger screens it can be quite a pleasure to see just the actual content and not all the clutter around it, which is usually of zero interest when you work on the content. I still remember when something like two decades ago (was it Word Perfect? MS Word?) I really enjoyed the fullscreen option where everything but the virtual paper was removed from the screen, so the actual content could be rendered with as much pixels as the physical screen has, and the screen was as pure as could be. Similar to what these days programs like FocusWriter are also specialising on.

Update: See the blog posts from Peter Penz and Martin GrÀßlin from the day before on a related discussion about what to do with the menu bar, i.e. how to fix the cluttering it creates and how to gain the screen estate it takes.

Kudos to the developers of KDE Games and the artists responsible for the pretty graphics, the KDE Games are really some nice shiny diamonds. And addictive, as my flat-mate just proved when I showed to her what I worked on last week-end πŸ™‚

Thanks also to the organizers of the sprint, Josef and Stefan, as well as to the supporters, as represented by the KDE e.V.

Advertisements

Okteta and Kasten on MeeGo

Having been caught by some cold two weeks ago, I was still lucky to have recovered enough in time to go to the MeeGo conference in Dublin, sponsored by my employer openismus GmbH, joining a bunch of my colleagues. It was a really great conference, will be a nice challenge e.g. to match it with the Desktop Summit in Berlin next year (remember the date, August 6-12th). Having arrived there the evening before, we added our part to the success by helping out with putting up the large stickers to the windows, which gave directions and set MeeGo theming to the rooms (Openismus – your (now) also experts in applying large stickers to windows).

It was nice to see how many of the people on the floors were real life animations of the avatar images on Planet Gnome and Planet KDE. And even more great to see and hear KDE oldie and now director of the AMD Operating System Research Center, Chris SchlΓ€ger, announcing that AMD is going to join the MeeGo project. Things are getting together which ought to get together!

A very welcome idea of Nokia and Intel to improve the motivation of the people to contribute to the MeeGo project was the give-away of a Lenovo ideapad for each conference participant. While the MeeGo Netbook release 1.1 is still anything but capable to make use of the multitouch feature of the ideapad’s screen, it for sure will be a nice device to experiment with new UI principles.

Which I am looking forward to do. While the work on my experimental Kasten framework has pretty much stalled this year, I hope I can pick that up again once my transition to Berlin has been completed (which could have been more smooth 😦 ). At least I took two days off and joined the KDE Mobile sprint starting the day after the MeeGo conference, hosted by KDAB in their Berlin office, thanks to them (incl. the delicious orange-tiramisu on sunday from Till’s wife’s birthday party, even if it was just a left-over πŸ™‚ ). While I happened to be part of the team which started the profile-oriented modulization of kdelibs at Tokamak 4 in the begin of this year, my only real contribution so far has been to propose (talk is cheap πŸ˜› ) the removal of the deprecated api+code for the “mobile” profile, to help a little in shrinking the size of the packages of the KDE Platform/Framework, then lost track of this topic in general. The more I was surprised now how much has been done already, great effort by whoever was involved (mostly Kevin Ottens, I guess?).

With no real touch UI oriented code for Okteta and Kasten yet (okteta-mobile is mainly main() atm πŸ˜‰ ) I used the sprint to join the “porting” efforts to MeeGo, which is basically rpm packaging. And removing some deprecated stuff here and there, as the kdelibs packages for now are created using the Mobile profile, thus having none of the deprecated APIs, quite nice to see how clean all the code is already regarding usage of these. Of course I worked on the packaging of kdeutils and also kdesdk, now that Okteta is part of kdesdk. The few hidden deprecated calls left in Okteta were quickly patched away, and there is was running on my new ideapad:

Sure, nothing as useful and shiny as others are doing, but then Kasten still has way to go πŸ™‚ Hopefully there soon will be long and cold winter nights and a new flat in Berlin. I know what I will do!

And while it is great to see GTK and now Qt being used and developed by the top companies, it is even greater to see other UI related FLOSS making their way into normal industry products as well, including upstream contributions, e.g. EFL on fridges. Things are really moving in good directions πŸ™‚