Author Archives: Marco Martin

KDE on MeeGo

This entry will show off a new cute thing, while also being a pretty shameless call for help 🙂

Last couple of days i was playing with the MeeGo sdk, it’s still a very young system but is really interesting (probably also exactly -because- it’s so young)

After installing the meego atom image on a netbook (by basically copying everything by hand, don’t think there is already an automated installation procedure yet?) and after updating all the packages I noticed at the current stage there indeed -is- a working X11 on it, so the subsequent step was quite obvious of course 🙂

The setup of the main SDK on the development machine as described on their wiki is really straightforward, so having a complete chrooted build environment is a matter of a moment.

Then i started to build a trunk version of KDE… almost all packages -required- for a build are already available (and recent enough 🙂 in the standard MeeGo repository, so I did a pretty basic build (with optional stuff kept to the minimum, will be important to decide carefully what would or would not be included in a build for that, since is targeting mostly low power mobile devices)

The result can be seen in this video (of course with Plasma Netbook shell, since we are on a particular environment like that)

As a side note on this video, is also show some new features of the Plasma Netbook shell in the upcoming KDE SC 4.5, but this is another story 🙂 (will do screencasts on those shortly)

OGG version

It can be seen that the boot is really really fast, and the performance is quite good too. It is significantly faster than on an older X11 on the same machine, however there are still some graphics glitches (not present on OpenSuse on the same machine) But I’m confident all of this will be gone on a new release of video drivers/X11/Qt (we have been here some times already after all :))

So, moral of the story, this shows KDE libraries and apps can be build really quickly there, they can work really well and that is the platform where some of our new projects can really shine, like the Netbook, the Mobile and the Mediacenter shells. Now think about for instance remote widgets between a mediacenter and a phone, or a phone and a netbook, just to name some of our technologies that would really come to full potential when having them on different devices

So, if you know how to do -good quality- packages, (that honestly, is really -not- my expertise :)), maybe already involved in the MeeGo packaging effort, some help will be really really appreciated, it would be really cool to set up a repository that people can use to quickly install a whole KDE stack on a (at the moment still text mode only) MeeGo install

On screen keyboard

In in an old screencast for Plasma Mobile, you seen a demonstration of an on-screen keyboard, it was a working proof of concept, but the interactin was still a bit wonky…

I love when those things happen: The autor of that plasmoid, Bjorn Ruberg (hats off) seen it and wanted to do something about… the result is a completely reworked widget, (that will be shipped with SC 4.5) now it’s faster, it has a way smaller memory footprint and more important is way more accurate now. typing on it has became quite fast.

In this little video it’s shown the keyboard widget working in an external little app that takes over a part of the screen (designed for small mobile devices) on the small Jax10 and on a larger old via-based tablet.

OGG version

Small goodies

This micro screenshot has two new little features that will come for KDE SC 4.5:

monochrome and blur

KWin team worked hard to write a new cool effect: blur under transparent windows: the plasma theme will notice and use more transparent windows if that effect is enabled
Monochromatic icons support for systemtray icons that use the new shiny protocol (dependent from the Plasma theme)

Small mobile update

I’ve been mainly working on polishing the systemtray and the Netbbok stuff lately. Among the other things a massive rework of the Search and launch nterface, but sadly it’s one of those architectural things that opposed to an huge change in the code there is barely anything to see visually 🙂 well, actually there is a new animation effect that i will maybe screencast later, but changes are mainly under the hood.

But this doesn’t mean i did neglet our new born baby: Plasma Mobile

It also had some not easy to see under the hood change, but this made possible to implement what it was just a gray background stub in the last screencast.

As we seen, we have a main view, with the “activities” (there will be useful widgets here like fast updates on social network services, presence on im network, summaries on new messages such as mails and sms and things like that)

Clicking anywhere not occupied by a widget makes the entire screen flip, showing launchers for all installed applications, categorized by the main activities. At the moment what’s it’s showing are results of KRunner queries.

In this video you can see how the thing is already basically working, both the effects, (quite fast already even if there is still a big optimization work to do) and the functionality of the widgets as well of the main launcher

OGG version

Get the bleeding

Today, as Aaron and Frederik said, we just launched a really cool thing: periodically updated images of a reference distribution for KDE Plasma Netbook. It’s done with the openSUSE build service and is based on opensuse; however it’s quite customized with our artwork and settings, so the general feeling of the distribution is exactly what the name suggests: a reference.

Search and Launch

It is (or, will be since we’re at very early stages of development) how we envision a complete system that boots straight into the Plasma netbook shell, and to be also a way to quickly test the really really bleeding edge development version without messing up your own system 😉

It is also very easy to customize the build on the openSUSE build service to make your own branch, so remixes and sperimentations of new ideas is really welcome 🙂

Here you can find the usb stick image, and here some useful documentation on Techbase.

Again on the unsystemtray

I see last entry sparkled a bit of discussion, so a recap is needed on what are the goals of our redesign for the ground up of the systemtray, form the low level protocol to the visualization.

The systemtray was almost always intended as a “notification area” (this always was its official name) and most implementation until now failed at it. The Windows systray failed because every commercial application wanted to put its “brand” on it, the X11 systemtray failed even in a worse way, because there was zero communication between the applications and the systemtray and there was no semantics at all in the items.

So the visual representation had to be pretty limited, it could just put there all the icons that registered themselves and nothing else.

The “notification” nature was failed by the fact that is was just an huge disorganized list of everything and the kitchen sink, so the option to manually hide some of them got in. This was again a failing of the notification concept, a manually hidden notification item can’t notify anything right?

But hiding icons would not be a bad thing if you can ensure that the ones that are actually notifying something are indeed visible, so -manually- hide/show icons can’t work.

That’s one of the reasons we wrote a whole new protocol for those items, called StatusNotifier (and -not- sytemTraySomething), this is already being implemented from third parties, for instance the next Ubuntu release will make extensive use of it. In the new protocol, an item is in a passive state unless it decides it really needs to be active (i.e. has some useful status information, like the battery charge) or is notifying something really important (like, the battery is running out).

Any information that doesn’t belong to the latter two cases, simply should not be there, as well doesn’t belong there its usage as a tiny taskbar, that will go completely away in the future (probably to go on another widget or in the taskbar itsef).

As a result, the visualization (that is what’s is improperly called systemtray) now can use much more data than before and can give to the user a representation that makes semantically sense, like showing only “real” notifications in the notification area.

Now the hidden items are a menu, because since an hidden item means it has no notification value, it just have an “interaction” one. so you probably need to access it just to trigger a function, like accessing one of its menu items (that will become a submenu of the main menu) and not anymore.

This design is a radical departure from the previous one (I would go as far as saying that is not a systemtray anymore, or at least that should be the target), so in the current Plasma widget there will be no room for the old behaviour anymore (so no configuration option to make it behave like a totally different widget, that should indeed be shipped as a different widget). However, the modular nature of Plasma, makes it really easy to replace the widget with a different one, maybe derived from the 4.4 branch (that by the way will stay buildable for the whole 4.x lifetime), so if there will be enough demand, rest assured a different widget for your needs will be available somewhere.

Small systemtray change

And now a new micro feature for KDE SC 4.5 🙂

Since today you’ll note that the expand button on the systemtray got rotated: weird isn’t it?

closed 4.5 systray

That is because it doesn’t expand anymore the systray to show hidden icons, instead when you click it, this is what happens:

opened 4.5 systray

There is a popup menu with all the hidden items in it, perfectly interagible and with a text label near to them: the rationale of this change is simple:

Hidden icons are rarely seen, it could be hard to recogniza them when you need one, so the label is very helpful
Often you expand the panel only to access a function of an hidden icon, then you don’t need te expanded systray anymore
Expanding the systray the unhide button actually moves, so it’s not immediate to close it again
When the systray is open, there is no way to distinguish icons that are norally visible and hidden

This has been done pretty early in the 4.5 cycle, so it’s still open for change, feedback and the due bugfixes 🙂

A vertical Plasma

Two little extra videos linked to the previous post, this is always plasma-netbook and plasma-mobile running on the JAX10 with Moblin, this time with the screen rotated to vertical.

It is a bit of an hack since the device doesn’t have an accelerometer and the touchscreen needs to be recalibrate every time the screen rotates, but is neat as a proof of concept, because neither Plasma Netbook or Plasma Mobile were never designed thinking about vertical screens, but in both cases, always keeping in mind we are at early prototype stage, they work quite well.

Something to be noted, fullscreen plasmoids tends to look a bit better on a vertical screen rather than an horizontal one, and our on screen keyboard works already quite well, even tough it’ll need to show less keys when in a tiny screen

OGG version

A mobile Tokamak

So another Tokamak went by, it is always sad to leave from this amazing group of people, but there are also two good things on that: 1) you know you will see them soon. 2) you know a really impressing amount of work has been done.

One of the big focus points of this meeting was how we tackle the new mobile devices, from a Plasma and more general KDE perspective.

It was a bit strange for me, because it didn’t involve as much coding as usual, but a lot of work on getting the KDE build working well on a particular mobile device.

We had three Compal JAX10 devices loaned from Intel with installed an image of the Moblin environment, version 2.1. While both software and hardware wise they are still a bit far from a “commercial” release, but that’s exactly what makes them interesting.

This is a device with capabilities pretty near to a netbook, however it has a totally different set of limitations and requirements.

Here we don’t have a normal keyboard, but just a little slideout one, and we have to remember that some of the devices of this class won’t have a keyboard at all. Of course there is no mouse/touchpad as well, this means all cursor input is done via touch screen.

With a touch screen some interesting things happen: precision becomes really poor, so we need bigger targets. Moving the cursor and pressing the “mouse button” happens at the same time, so you can just click: anything that relies on mouse hover becomes immediately useless. Screen edges, the most reachable area with a mouse, becomes the less convenient one to use

Anyways, it was an interesting experiment: how far we can get, in a single week, starting from the bare libplasma to do an user interface for a device like that?

In the end we ended up not with one interface but with two: I adapted the Plasma Netbook interface to some of the quirks typical of a touch screen (a lot work still has to be done) and I obtained something that works quite well as a general launcher for touchscreen based tablets, that still can use an (adapted of course) version of desktop applications mixed with the “newspaper” concept (where “turning pages” will become a really natural concept) and Plasma Widgets that will run as a full screen application.

Here is a short video of the Search and Launch usage (a rough prototype had already been shown some days before Tokamak, now it’s starting to work really well): it shows the horizontal scrolling of the results when the little touchscreen is landscape and the drag and drop of items around: really important there since the little actions on mouse over don’t work there: also for deleting them a particular drop target with a little trashcan appears. Another important point is that now on a touchscreen a drag (being of the results view, of an icon around) begins with an enormous treshold compared to a desktop/netbook: in this way it adapts to the really low precision that a finger has on a touchscreen.

OGG version

And the last concept brings us to the design of the other user interface: on a really small mobile device, such a phone, it will become simply impossible to use the regular full applications (logic and ui will have to be decoupled). Many Plasma widgets have a quite small UI, so as far as real screen estate is concerned they can work suprisingly well on small screens, they also make extensive use of touchscreen friendly concepts, like flickable scrolling views and drag and drop (even some basic multitouch support, like pinch zooming, if ony X could :p)

Some widgets, like the Opendesktop plasmoid work really well already, with just some fixes to be done here and there.

Another advantage using the Plasma widget library is that being based on QGraphicsview, they are on top the same framework of Maemo 5 and Maemo 6 ui, allowing coherence and interoperability.

On devices like a phone, we will probably also need a different primary user interface, since the size will be even smaller, not only in terms of resolution but most important, in terms of real size (the JAX10 and the N900 are both 800×480, but the N900 has more dpi, so a smaller screen)

Another reason we can want a different ui for a real phone are the main use cases, for instance here i want to be able to reach the actual phone dialer with as less gestures as possible, and the target use case is even more “casual” for function that are not related to telephony itself.

We had some design sessions about the use cases, interaction paradigm and code design of it, then Nuno produced some really beautiful graphics and mockups. Artur and Alexis sat down and implemented a proper full featured plasma shell over that mockup and got it working in an impressive short amount of time. As I said, I couldn’t code much on that (but I plan to fix it in the next days;) because my job was mostly getting everything working on the JAX devices, so long sessions of building, patching, rebuilding testing, fixing and rebuilding again. Artur has a really interesting post on it too, as well as Alexis.

At the end of the week we produced a video that once released (will take some time to edit) will explain what we did and our plans in detail.

As a preview, here are two short videos that show what we got at the moment.

OGG version

Tokamak, days 3, 4 and 5

Days at Tokamak are running out very quickly: last days we had a very frenetic activity: for me it was spent mostly around adapting aspects of the Netbook Search and Launch interface for touchscreens. It’s impressive how good it looks already with so little changes of code

Alongside of that, we are designing a different interface for another different kind of devices: smaller mobile devices, as small as smartphones (hello n900 🙂 or various ways on internet tables.

We have here some N900 and 3 little tablet devices lended by Intel (Compal Jax10 with a Moblin image installed on it actually). I must say the Moblin SDK is quite easy to use, I’m pretty happy with it.

It’s really important for us to actually get going on mobile devices, because with our platform as insanely flexible as it is, we can deliver a really coherent user experience across the board, starting from the desktop, going down to the netbook, to little tablets and cellphones.

Almost entirely different UI, but with an impressive amount of code shared between totally different form factors. That’s the beauty of having a clear separation between the logic and the ui, having a rich framework that helps to keep the ui layer as thin as possible.

We’ll also going to expand theming capabilities by offering the possibility for Plasma themes to offer custom animations…

What does it mean? It will be able to customize the user experience a lot, not only with different desktop themes, but also across different devices, where the interaction patterns and different resource constraints.

It will use of course Javascript, for usual requirements of multiplatform deployment without rebuild and more robustness/security/ease of writing.

In the short term what it means? Expect tasty screencasts in the next few days and new cool shiny toys to play and develop with in the next KDE SC releases.