Tag Archives: tokamak

A mobile Tokamak


Suse officesSo 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.

Everybody hackingThis 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

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.

Tokamak 4, day one


Arrived yesterday in Nuremberg with the rest of the italian Plasma gang (we wandered half an hour in the -wrong- building in searcch for the hotel reception, quite a surreal experience :p)

Today is the first “real” day, there were a lot of great talks, all of them revolving around our future direction, what’s coming for 4.5 and what’s coming beyond, so expect quite a bit of blog posts about that in those days πŸ˜€

I’ve talked abount, surprise surprise, the the Netbook shell πŸ™‚

I’ve talked about some technical details about the various components: what is the different between the Netbook and desktop shells themselved (just the tiny binary), how the search and menu of the Search and Launch interface are done, how is done the new shiny drag and drop, and everything about the newspaper

In brief, for the future, expect a big effort about polishing and bugfixing, to get an experience as smooth as possible (like a cache for the newspaper widgets when the device is offline) and expect some new features, like maybe free resizing of widgets in the newspaper.

Looking back at Tokamak 3


I’m starting this entry on the train on the way home from Tokamak (and finishing it at home). Looking back it was probably the best KDE event I ever been. I’m already missing each one on every person that was there.
>Fisrt of all I want to thank Mario Fux forhosting the event. It was a really big job for him and everything was gone perfectly smootly.
The place was of breathtaking beauty, I didn’t brought a camera myself but you can see from other blog entries on planetkde photos of this beautiful place. Last day we gone at the bottom of the Motterhorn mountain with the cablecar. This mountain is beautiful because it’s an huge block of rock of the exact shape you would expect from a mountain, really makes you remember how tiny human being are on this planet (yeah, sounds clich

Say something Tokamak


Didn’t really find much time to blog at tokamak. Anyways, what I’ve been doing?

  • The netbook shell has found a new home in kdebase, so now if you build trunk it will be here and will definitely be here for the release of KDE 4.4. This is realy important because it makes easier for people to try it right now without having to compile components from playground. Another important reason for the move is the reuse of the existing coomponents, in particular the new widgets explorer that has been merged from the Gsoc project of Ana, that makes the experience of both plasma-desktop and plasma-netbook much more pleasant. Not much to add right now but stay tuned for a screencast in the next few days.
  • The KnotificationItem library, that is the client of the new systemtray specification has been merged in the KDEUI module. This means is no more experimental and all applications can start to use it without fears of binary incompatibilities. At this point the start of a Freedesktop standardization seems much more realistic.
  • Ad oh well, we are all been busy in refactoring and moving aroundstuff, so while there could be some instabilities in trunk right now, the plasma library will become much more clean and robust in the future.
  • Anyways, many props goes to Rob and Ana that have gone trough the endeavour of merging their pretty big Gsoc projects, this did mean work and work and work, but i’m speechless about the quality of the projects. Ana’s widget explorer makes plasmamuch more usable and pleasant to use, Rob’s remore widgets are well, revolutionary, can’t find other words, but i’m not gonna to explain them here, they can do a much better job.



Yesterday talks were wicked interesting, especially the Alexis talk about the new animation framework was really breathtaking.
Aaanyways, this is kinda a synopsis of what i talked about in my part during
the talk session yesterday at Tokamak, slides
it’s quickly written in few minutes, so the english it’s a total horror,
but i feel it could be kinda interesting anyways πŸ™‚


Pretty much everything you see in Plasma is based on SVG graphics,
this means that you have a really high degree of customizability
controlled by the Plasma theme. This also means that compared to
classical Qt themes the entry barrier is significantly lower, because
of course you have to be a good designer to make one, but not a
programmer, while to do a Qt theme you have to be both and this is a
really really rare thing.

Also, since themes are pure graphics without binary code they are
completely platform independent so they can be distributed trough the
GHNS framework.

Being vector graphics, we can display them without problem from
very little screen to huge monsters when we will have 600dpi screens
that won’t be a problem, specially for the theme elements based on
the FrameSvg concept.

From a programmer point of view using the theme graphics is quite
easy too, because the two main classes that manages Svg themes (Svg
and FrameSvg) are very abstracted, so you won’t have to bother that
the graphics is actually a Svg.

Plasma themes will be installed under your KDE installation prefix
under share/apps/desktopthemes. The filesystem structure inside the
theme has got two main subfolders: widgets, meant for element
drawn on canvas and dialogs, meant for elements that are
actually a top level window. There are two particular and optional
subfolders: the first is locolor, that will have the same two
widgets and dialogs subfolders meant to be used when the theme is
displayed on screens with less than 16 bit color depth.

The other folder is called opaque and has replacements for
the elements that are a top level widget when the desktop effects are
turned off, that’s because in this case we won’t be able to have a
semitransparent window, so we won’t be able to have luxuries like
antialiased borders or drop shadows, if you have a rounded border
there you should use the good old pixelart tecnique from the 80’s.

In order to load an Svg from the current theme is sufficient to
use the setImagePath() function of Plasma::Svg, where you don’t have
to worry neither of the path of the theme or the svg or svgz
extension, so something like “widgets/background” will suffice.

If you are writing a scripted applet you can also include the
graphics alongside the applet code and distribute everything in a
single package, from a javascript applet for instance it will be
sufficient to call the function plasmoid.findSvg(“foo”) and the
proper foo.svg file will be located for you.

That said however now i have to get a bit annoying with some
advices: you should be really really careful when you add custom
graphics in your applet, both when you install it alongside your c++
applet and also when you embed it in the package of your scripted
applet, because your additional graphics must work with as much
themes as possible, and this is an hell lot difficult. You should at
least try it with both a dark and a light theme, but in the end… if
you want to do that, think again πŸ™‚

Boring implementation details

Usually in your applet won’t have to directly paint Svgs, because
if you just use the default plasma widgets you’ll have the svg
painting done for you, but if you have to draw some svg elements you
have to know two classes: Plasma::Svg and Plasma::FrameSvg.

The mighty machine that manages all the svg painting in Plasma is
the Plasma::svg class, that internally uses the QSvgRenderer class,
but optimizes it as much as possible: in the context of the whole
Plasma application for each svg file we get an unique shared svg
renderer and the rendering result is saved to disk thanks to a
KPixmapCache, that can avoid the creation of renderer to a satisfatry
degree: in the second plasma start won’t be created a single renderer
until you resize something, saving a bit of startup time and some
megs of ram.

The most important functions you are interested if you want to use
a Svg are its several paint functions (overloaded with QPoints or
QRects as parameters) the already mentioned setImagePath() resize()
and various functions to access the svg sub elements like
hasElement(), elementSize() and elementRect().

The other class used in plasma to render Svgs works at a slightly
higher level of abstraction and is Plasma::FrameSvg. Usually widgets
are mostly rectangular things, but even if Svg is scalable that
doesn’t mean the result will look pretty, take a look at the slides
example for instance, where a
default applet background is heavily vertically stretched, so the
horizontal borders become thicker that the vertical ones, and to make
things worse they usually aren’t even an integer number of pixels
making the result to look really blurred.

So, what is there in the default applet background? We can see
there are actually 9 pieces: the corners, the edges and the central
part (called with a great stretch of fantasy center, top, topleft,
topright, left,right,bottom, bottomright and bottomleft). When the
thing will get painted not all elements will be scaled, it’s
important that the corners won’t be never ever scaled, while the
horizontal edges will be scaled only horizontally and similarly the
vertical edges will be scaled only vertically, while the center
element will scale freely.

From a boring code standpoint FrameSvg inherit the Svg class, so
all the stuff that is available in Svg is available in FrameSvg too,
but with the difference that you want to resize the image with
resizeFrame() that uses the method i talked before and you’ll paint
the correctly resize Svg with paintFrame(), while paint() is still
useful to paint single elements in the Svg. Also a single Svg can
contain multiple series of 9 elements, with the names differentiated
by a proper prefix, that can be chosen with the setElementPrefix()



As I’m writting this right now I’m on the train from Milan to Turin heading back from TokamakMKI, unfortunetely i’m leaving early because an old 3vil exam (oh C.E.Shannon, you know i love you, honey:P)

It’s a shame i hadn’t found time to blog about Tokamak until now, but when you can hack all night long with an overdose of astonishing KDE people (and the even more astonishing our overlordness P-man) the internet suddenly becomes a boring useless toy πŸ˜›

In this meeting we managed to literally turn Plasma upside-down, well done his WOCiness Alexis! (light hearted readers are advised against trying to compile today’s svn) and other reeeally cool things like wastly improved javascript plasmoids support, add activities interface, start of an awesome looking krunner redesign as pretty as the new Twitter plasmoid, new applets and oh gosh, I’m too tired right now, I’m forgetting a really big bunch of cool stuff, their respective authors are officially authorized to stab
me to death πŸ˜€

I did a lot less than I was hoping but i managed to get movable resized panels (no configuration interface for you today:)) that can be seen in this reeeally crappy-looking screenshot:

center panel, oh yeah

Oh and yeah, as you can see a cashew is grown inside the panel, we’ll grow it with care and love, what’s his purpose? we will be able to configure the panel from just here instead of a losy 90’s looking right mouse button config dialog.

Did I mention that this screenshot looks like utter avariated crap? So i have a little spoiler for you: toghether with the Almighty Nuno we have defined how the panel and a new default Plasma theme (and the aspect not necessarily linked with a theme) will look like, and it will blow away pretty much everything you have seen before on any thing (well except for pink flying elephants of course…)

How it will
look like? not so easy, you’ll still have to suffer quite a bit waiting to see that πŸ™‚