Category Archives: BlaBla

Tokamak netbook talk

This post is an attempt to make a little synopsis of the stuff i talked in my tiny presentation about the Plasma Netbook project, nothing new but a nice recall.

The plasma netbook shell idea was born during Akademy 2008 in Belgium on a blackboard (yeah, real old blackboard with dusty chalk :p) and remained mostly on the blackboard for quite some time.

However the first pieces were put in place shortly after by Aaron doing a first implementation of the plasma shell, that languished there for a while.

Fast forward until some months ago, me and Arthur decided to put some time in it, so let’s see the results so far.

As plasma being really modular, we now have a collection of stuff pretty much independent suff.

A plasma app: we don’t use the plasmadesktop executable but something that is lighter, simpler and allows us to experiment very un-desktop things

We have some own containments too:

We don’t use the normal desktop and panel in plasma-desktop since it has too many things not really useful there: logics for autohide panels panel alignment and things like that

Newspaper containment. A free layout is not adapt in a constrained size, let’s put a bit of order.

Search and launch. Let’s have an easy and intuitive way to launch applications and do searches, without monopolizing the whole ui.

Just two applets right now:

A search box separate from the sal, to be positioned in the panel

a simple titlebar/semi-taskbar, since we won’t have neither of those

We can ask ourselves since we have a really good desktop: why we do a different thing?
A traditional desktop has some characteristics that makes it really good on big screen resolutions since we can tile multiple windows in the same screen or leave a big emty area to access the desktop.

However on a small screen the very concept of havin windows become annoying, because the space is barely enough and sometimes even too scarce for the actual application data. This Should drive us to a radical rethinking of how the shell should look like and behave and is also an occasion for us to have new ideas and touch things that in a desktop we really can’t.

So what we have that is so odd? We don’t have a desktop containment, we don’t have a taskbar, a titlebar of the windows or resizable windows.

A peculiarity of the shell is that the main view, what usually would be a “desktop” is a normal window like the others, so is possible to put it in front and choose it in the “taskbar” (that is just the present windows effect) and in alt+tab, also all the panel configuration machinery is not present in the shell.

What is really interesting of the project are the two new containments.

The newspaper: the idea is to make look like a newspaper, act like a newspaper, so it’s a duck..

This is what you see as soon as the system start: a two column layout of widgets that are network-oriented, so they gives you a quick overview of what happens in the interwebs and on what your friends are up to.

The Search and Launch interface: from personal experience i see that new users are simply amazed by krunner when you show it to them, but they rarely use it, because it’s really well-hidden under a shortcut and there is nothing advertising it. On the other hand the SAL interface brings krunner up as the first and only way to launch applications (or execute any other kind of search and action supported by krunner, from evaluating numerical expressions to searching wikipedia)
the search box is in the panel, so it’s reachable even when the sal containment is hidden by windows or is not in the main view.

There were interesting reactions so far. The comments about the newspaper and the sal were overwhelmingly positive, way more tat i expected, that says we have to be doing something right :p. Not so positive are the comments about the panel, i think tere are some valid points and i am not really happy about too, there is certainly room for improvement.

Now, the work still to is still huuuge (everyone willing to give an hand is of course more than welcome):

Refine the applets and containments: better fallback in the case desktop composite is not available.
Improve panel behavior

Friendliness to keyboard navigation

Integration with kwin: how to do and behaviour of the fullscreen applications

Seamless switch between a plasma-desktop and a plasma-netbook session

Make really smooth to use certain plasmoids as stand alone applications

Pretty system tray: not just about icon themes

It’s good to see other parts of the OSS community looking at the current state of the X system tray and not be satisfied at all, it’s good because as you can see from this blog, i think the current approach is really really limited in many ways, as it was explained several times…

This time is about look… now, the idea of having monochrome systray icons is actually quite good, but is quite a pita with the current protocol and actually a good use case for the new one.. why?

Let’s say we have a black panel (as the mockup of jono’s blog), so it’s reasonable to expect we want white icons, but what about if we suddenly change our color scheme to a light colored one? (or plasma theme in case of KDE)
Of course the icons will become invisible, so we could need to change all of them to another theme on the fly, and this could mean also that those icons can’t belong to the system wide icon theme, or we could have to change the global theme just for the systray, that’s no good, right? 🙂

Now, the current systray protocol requires that is the application itself draws its own icon, and this theme-dependent icon color switching is kinda possible (just open the configuration of the panel… by every application) but it’s really clumsy and not cross desktop at all.

The dbus based systray protocol we’re working on requires instead that is the systray the one who paints all the icons, and being part of the panel of course it knows well what the color scheme is.
The icons can be sent in Dbus by data, passing all the icon bytes themselves and in this case of course we can’t do much more than painting what it arrives, but the recomended way is to just pass the icon name (following the icon name freedesktop spec of course) and in this way we can decide where to pick this icon, we could have systray-specific icon themes dependent from the color scheme (falling back to the system wide one of course)

Now, I don’t know if we’ll actually implement a thing like that and if it’s worth the effort, but it’s a while we are talking about that thing and i think soon or later I’ll give this idea a spin 😀

Gran Canaria

It really doesn’t seem true GCDS is almost over (just a day remainig, how sad :/), and I’m kinda realizing just now that the internets actually exists, so I didn’t blogged at all while here, that happens when I can actually talk in person to most of the internet I care :p

What I can say, the location is fantastic, met some old faces and some new (hello, gnomies :p) and the whole thing has been quite productive, maybe not much on the code side but definitely on the design and the planning part.

We have got some crazy ideas about the ZUI and there is a new plan of collaboration with Kwin that will make the workspace even more integrated.

I’m also veryvery happy with the progress so far by our gsoc students (unfortunately only Chani and Ana are here, this period of the year kinda sucks for students unfortunately), most of their work will probaly be in KDE4.4 (being tired at late night made me write KDE 4.2, DOH!:P)

But what I’m more excited is the Plasma on Netbook project, if the implementation will go straightforward enough, it looks like we something usable is not too far ™, stay tuned :). WEll, actually don’t try to use it now because me and Arthur are turning the thing upside down at the moment, so it will eat your children 🙂

And oh, besides
that on the coding side I’ve continued the work on the embedding of plasmoid into the system tray, continuing our plan to show only what you need, when you need it, screencasts about it to follow in the next days (probably when i will get back home).

Spread your knowledge

As Frank said yesterday in KDE 4.3 there will be the beginning to the support of the OpenSocial API, this is still fairly limited and at an experimental stage, but we did roll out something, to test the libraries and get people use it, bot users and programmers.

So now we have basically 3 things:

A client library (lib Attica) that connects to the opendesktop.org API, supporting a part of the specification.
A Plasma dataengine that use said library
An Opendesktop Plasma widget that displays the user profile, lists friends and geographically near users (and if you are in a foreign city with your laptop that’s beyond cool :D)

For this work many props to Sebas and Cornelius that did most of the work 😀

What i did was the support for the knowledge base into the library and into the dataengine, and this luckily made into KDE 4.3

Now a plasma widget is in progress, that is in playground as usual, and will be in KDE 4.4. (probably i will make a standalone release on kde-look before, if it won’t use too much 4.4-specific code, but i always tend to make uber bleeding-edge code, soo we’ll see :p), you can see the result here:

OGG version

Entries of Opendesktop items, (so kde-look and gnome-look themes, kde-apps and so forth) have a knowledge base associated to them where users can ask (and of course answer) question about them, with this plasma widget you can search and browse the questions and answers about all items on opendesktop.org, where another interesting application of the concept is to search into the knowledgebase for instance of a particular kde application… directly in the application itself. and since a general purpose library is getting in shape, that will be quite easy actually.

Aaand hopefully with this competition we can find new contributors to the project (we poor plasma developers can only do so much, right? :P), so if you are interested in doing something for the KDE integration, make sure to check out the ocs dataengine with the Attica lib (in kdeplasma-addons) and look at it both as and user of them (i.e. to do cool widgets or other apps) or to contribute to the library itself 🙂

Put a net in your book

Ok MoRpHeUz, i’ll show it :p, so here we go:

What’s that screen? it shows the embryo of our idea of user interface for a netbook. the actua plasma executable is another one that is way simpler that the full fledged plasma-desktop one, and it features just a panel (final layout still to be defined) and a main view (don’t call it desktop eh:p) that will display one of the two main activities we will ll come up for this project that are: SAL, a fullscreen application launcher/search interface/document browser/whatever (MoRpHeUz will talk more on that in the future:p) and the Newspaper activity, that’s where i spent the last 2 days of development, besides making the mini plasma shell work a bit better.

The idea is the following:
It’s an activity that displays a big scrollable view of widgets in two columns (with all backgrounds melted in only one to look less crowded and to save space), so it’s designed to look just like a newspaper, the idea is to put many net oriended widgets in here, like a rss feed browser, weather, opensocial widget, microblogging and stuff like that, to give a central overview pointon what’s going on in the online stuff you’re interested in, kinda like scrolling trough an actual newspaper (with the difference that here you build it as you please) and from each one of the widgets you will be able to open a more detailed view of the item displayed in the widget. With a more detailed view i mean opening the proper application to view it, that could be a browser, could be akregator, gwenview, whatever.

For now there isn’t much more than that, so i can just say stay tuned! 🙂

The smallest media player in the world

As I was showing here now Plasma in trunk can also play video/audio files, so what will be there in KDE 4.3? Basically two components:

The first is a media player widget (or applet, or whatever…). It will be the basis for a future media center written totally with Plasma technologies (one of the exciting discussions we had at Tokamak2 🙂 as today it’s in playground and plays video files dropped in plasma, can open arbitrary audio/video files, has some usual control buttons and exposes the standard org.mpris D-bus interface used to control media applications, can be controlled for instance from the now playing widget, as shown here.

The most central component is in libplasma right now and instead is well, a media player widget :p
The difference is that it is a widget in the sense of reusable control to be used in the applets/widgets/plasmoids you write (so, wanna for instance make a youtube browser?:), it uses various components of Phonon, like Videowidget, MediaObject and AudioOutput and has a default set of control buttons that do a nice slide in/slide out on mouse over, and the reallt cool thing is that using it from the javascript bindings is ridicolously easy.
This is a complete plasmoid written in javascript in the minboggling amount of 6 lines of code:

layout = new LinearLayout(plasmoid);
video = new VideoWidget();
video.usedControls = DefaultControls;
layout.addItem(video);
video.url = startupArguments[0];
video.play();

All it does in sequence is: make a layout, make a video widget, enable a default set of buttons, add the widget in the layout, load the argument as the video if any (i.e, the file that was dag and dropped on the desktop), and finally, play.
This thing is in kdebase in the tests folder of the javascript based plasmoids.

Now, switching for a moment in hype-machine mode, think about putting together media content distribution, javascript, plasma, browsers and the not really happy state of these things in Linux right now, really far fetched for now and not for the immediate future, but good things can happen 😀

TokaTalks

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
here,
it’s quickly written in few minutes, so the english it’s a total horror,
but i feel it could be kinda interesting anyways 🙂

Themes

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()
function.

Merry Christnas

This looks more like a tweet, but just Merry Christmas people 😀

University

After many many years, way more of what i would have liked to, today i finished the university, with the defense on my thesis (a weirdo thing about ontologies describing European directives, a PHP+postgresql monster i’m quite proud about after all).

Now even if i will probably continue working in the uni for a (hope not too long) while, it’s really a weeeird sensation knowing that something that took over a quite big chunk of my life it’s actually over.

I hope to be able to continue to hang around and hack on plasma as much as i can, as i feel in the last year KDE became a quite positive part of my life that i’m very happy about 🙂

As long as I will still work for the university it won’t change that much, since i will continue to do pretty much the same thing, and after that, bah, who knows, but for now i don’t want to think about that, just be happy for a bit :p

Rotating your adult content

After seeing total coolness like this and this, i of course decided that Plasma couldn’t lag behind that total ratio of awesomeness.

This is an idea from right the begin of Plasma (we always had the MediaCenter formfactor impatiently waiting to be actually used after all:)

At the begin a thing like what I did today was not possible for two reasons: throwing qwidgets on canvas is possible only from Qt 4.4 and before Phonon was not able to render over widgets. In fact the first version of the Amarok video applet had to embed a window in the applet with the video in, so no correct z ordering, no transforms etc.. but now the good plan come together and is possible to render video even on the walls of a wolfenstein 3d maze (hats off to Matthias Kretz) 😀

The cutie in this video is a plasma applet that embeds a video, it uses the X-Plasma-DropMimeTypes directive in its desktop file, so it’s sufficient to drop a video file on the desktop and the applet is automagically created.