Tag Archives: plasma

Introducing Notification Icons

Software

This is the period of the year when Plasma developers exits from under their rocks it seems, so there i am too, i wanted to blog about that since quite some time, but i am really too lazy lazy lazy to blog :p

As Aaron said, last months i’ve been quite busy with the implementation of the new systemtray specification. At Tokamak we gathered around a whiteboard and discussed what sucked about the current X systemtray, so… what if we could design it from scratch? well, let’s do it! this thinghie interested me so much that i jumped over it in a coding frenzy with i hope a sane amount of pauses to think about it and keep the design sane, scrapping stuff when the design direction seemed to take an ugly direction, process that is still ongoing, so all i will talk about here is still subject to changes, rennnames, replacements etc, nothing “production” still :p

Soooo, why we were really unhappy about the system tray we have now so much at the point to want to design a brand new thing? (and enlightenment people too, and this makes me happy since will permit us to have a really cross desktop design from day one)

There are several reasons, so let’s see one by one:

Painting, positioning and behaviour

Right now systemtray icons uses the Xembed protocol, that basically means they are windows owned by the client application process (very very roughly and pardon for the inaccuracy, kinda like the systray was their window manager). This means the painting of the icon is controlled exclusively by the client application, the systray itself has not much to say about that.

It means also, since systray icons have windows, i can’t have two system trays, (they would steal icons each other, since the window representing the icon s well, one) and, since plasma is canvas based, the implementation detail of whet xembed is will brutally come out as soon as you try to put another applet over the systray or try to rotate the applet or zoom the view where the applet is, as you can see here :p (yes, that could be kinda achieved with composite, but still a real hack)

OGG version

Moreover, nowdays our panel is a window that uses argb visuals, so it’s translucent when desktop effects are on (that means basically force 32 bits color depth on all windows representing icons). and that’s a thing that neither X or graphics drivers (or even qt, before 4.5) were ready for, the amount of bug reports about visual garbage into the system tray or icons that becomes invisible (nowdays still happens with intel cards and the problem doesn’t seem to be headed for a solution) were really many and quite discouraging.

Communication between system tray and icon

Or better, lack of thereof in the current spec. Now, the system tray limits itself to embed all the icons there are around (basically windows with _NET_SYSTEM_TRAY_S atom set) and after that, it knows exactly zero about them. Why it’s useful for those guys to talk to each other? Well, we all know the problem of cruft in the system tray, having 10-20 icons that steals half of the panel length or more is quite common, unfortunately…

Windows starting from XP made a timid attempt to solve the problem, by auto hiding system tray icons that din’t have activity for a given period of time (don’t know how since i don’t know how their protocol works) or alternatively manually hide icons you hate (ideally shouldn’t be necessary but the world is not, nice and fluffy with rocket launcher equipped ponies, misbehavers will always be here)

Now, in KDE (and any desktop that works on X by the way) we can hide icons but only manually, because the system tray has no idea what icons have activity, what are trying to notify something or things like that.

another interesting tought can come by looking at a typical crowded (and not even really crowded) system tray, icon by icon:

average systray

  • The package manager screaming that i need super-important security updates: it’s a system service that needs user intervention every now and then, so it uses the system tray to notify that to the user.
  • KMix: it’s an hardware control utility, it sits in the systray to give the user a quick way to control the volume without having to dig into the applications menu or systemsettings.
  • Keyboard layout: it’s a system service, also there to give a shortcut rather than notify something
  • Nepomuk: it’s a system service usually it’s not really useful to have it in the systray, but becomes neat as soon as it goes into the systray just when it’s indexing, to notify the user that is doing many disk operations, so giving to him a quick way to pause the indexing if he needs hard disk performance in that moment.
  • Klipper: it’s a system service, that lets the user manage the clipboard, perhaps it would even make sense to have it in the panel out of the system tray..
  • Kwallet: also a system service, access to the saved passwords, not a notifying function at all, it’s the typical icon that should be hidden until the user goes explicitly hunting for it.
  • Konversation: it’s the status of a normal application, but it can be seen also as a communication thing, since those kind of applications tend to notify a lot they can be seen as a separate category (i.e, somebody is trying to talk to you, as in this icon)
  • Amarok: it’s the status of an application, the icon itself says if amarok is paused or playing and the progress itself. quite used because once amarok plays it can be keeped as a background thing (i.e not in the taskbar and forget about it as long as it emits noise :))
  • Skype: as konversation, it’s a communication thing, and also there the icon blinks when somebody tries to contact you
  • Kopete: communication thing too

So what we have there: several categories:

  1. Application status, like amarok in this case
  2. System service: like nepomuk
  3. Hardware status: like kmix or a battery or things like that

Application status icons in the future can be integrated into the taskbar for instance (did i heard somebody whispering dock? he will be punished :p), and even the other two categories could be separated in two different system trays, it gives more freedom to implement something that could exit from an usability study, with less fears of saying “ehmm, no sorry that can’t be done actually…”

The icons can have several statuses, we can think about 3:

  1. passive: informational, but doesn’t require really user interaction, so it’s a thing that the system tray can decide to not show if not explicitly asked (in this example would be the package manager when doesn’t have updates, kwallet or nepomuk when idle).
  2. active: the service is doing something or is a control that could be needed any time (nepomuk indicizing, package manager checking for updates, kmix that could always be handy there, battery indicator…)
  3. Notifying: the icon requires an action from the user, for instance the package manager with new updates, or somebody that tries to contact you from kopete.

So we can now display the notifying ones in a different area of the systray, with a different background and we can hide the passive ones, and show them only when the user presses the unhide arrow.

so what we have now?

The main implementation skeleton is done, the specification it’s all based on dbus message passing, since it has to be a cross desktop thing. It’s divided in 3 parts: a kded service that keeps the list of the applications that wants to use the system tray (so the list won’t be lost due to a plasma restart) the protocol support in the systemtray applet (our systemtray could already support multiple protocols, since it was designed already with this possibility in mind since the refactor in KDE 4.2) and a client library in playground with a tiny test application used as a proof of concept, that can be seen in this video (yes, not a mind boggling spectacular thing, but still important), with also an interesting feature: when you stop the systemtray bookkeeping daemon, the icon magically falls back to the usual legacy system tray icon, so an application using this new protocol would still get systemtray icons when running
in a desktop environment that doesn’t support the new protocol.

OGG version

The client library and the dbus interface itself will pass trough a tough api review, so they can still change in a quite significant way (that’s why i didn’t go really in details in this post).

So don’t expect in KDE 4.3 all KDE applications to have been magically converted to this new protocol, but i hope all the plumbing will be there to permit application developers to start considering using this, and i’m really looking forward for other projects to cooperate to have a new unified shiny stuff 😀

Responding the streetlights-glowing call

Software

Ariya called on who is going to turn the web-based google talk client to a plasmoid, so here i am 🙂
Let’s try with the javascript api:

layout = new LinearLayout(plasmoid);
webView = new WebView();
webView.url = "http://talkgadget.google.com/talkgadget/m";
layout.addItem(webView);

And the result is:

google talk plasmoid
google talk plasmoid

You can download it here (warning: trunk required).

Micro blog needed Macro love

Software

The Twitter Microblogging widget is a really useful tiny little utility, unfortunately until now it had severe appearance problems, especially when resizing the thing it did happen that contents could overflow from the applet boundaries.

This was partly due to some problems Qt 4.4 had with QGraphicsLayouts partly to our workarounds to those problems.

In Plasma we’re the childs with the slingshot that terribly enjoy to break stuff, the Qt components that Plasma uses, the QGraphicsView related stuff is a part significantly younger than the other parts of Qt, and we are putting it on a really tough stress test and this, even tough painful at start, it makes the framework mature at a really fast pace.

Now, i’m really impressed with the quantity of bugfixes present in Qt 4.5, so i decided to give the microblogging plasmoid another little quantity of love, and this is the result:

OGG version

So now the height of individual posts grows and shrinks depending on the text layout inside them and when the size of contents is bigger than the size of the widget it shows (or hides) scrollbars as needed (it’s also kinda touchscreen friendly since it can scroll by dragging the contents themselves). So now works more as it is expected to from day one, that wouldn’t be breaking news per-se, but it demonstrates that the stuff we were uber-early adopters it’s really coming together and show what its real potential was.

What’s more important is that not only the microblogging widget works better now, but it’s also easy to write a new widget like that, since the process produced two new widgets in libplasma (widgets not in the sense of plasmoids, yeah i know it’s confusing:): TextBrowser to be used every time you have to display formatted text simple enough to not require Webkit. The other one is ScrollWidget, where you simply slap another widget in it ant it will automatically decide when cut away a part of the contents and when to show the scrollbars or not.

The smallest media player in the world

BlaBla

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 😀

C’est magnifique

Software

This is a tiny plasmoid hacked on a boring sunday afternoon in about 20 mins, perhaps a too silly name but i think the effect is kinda fun 🙂

It’s an on-screen magnifying glass with the difference from the usual ones that it doesn’t actually grab the screen, but it just views the Plasma canvas (just another view on the scene, that is), that gives some peculiarities, shown in this video:


OGG version

All the windows are totally transparent to it, so while is useful to view/magnify just what there is on desktop it can give a quick access on it, when you need both your windows and stuff on desktop (think about a non-fullscreen dashboard, and then think about drag and drop between dolphin and folderview even when you have a maximized window :P)

And the more cute thing is due to the vector nature of the QGraphicsView, you see all the proper vector-based elements like the text to be smoothly scaled and still looking like text, not that usual pixelated/blurry mess that kinda hinders the utility of screen magnifiers as accessibility applications.

It’s amazing what it’s possible to do in plasma with a really limited amount of lines of code (here about 100, perhaps 20 or so could even still be saved:)

The thing now lives in playground and is still really rough, so not definitely 4.2 material, but who feels like can give it a try anyways:)

Rotating your adult content

BlaBla

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.

OGG version

This applet that lives in playground is highly experimental: no config options, no audio, no seeking, just bare working.
But it’s just the beginning, for 4.3 there will be a generic widget usable with few lines of code (even scripted of course) and a basic applet. Yeah i know, 4.2 is still far and the 4.3 teasing is started already, we are soo evil :p

A FormFactorized Plasma Quake

Software

Plasma always had this really cute concept of “formfactor”: in brief different areas where plasmoids can reside have different behaviours, for instance a desktop is planar, i.e. the applets can grow anywhere they want.

The panel on the other hand can have a vertical or horizontal form factor, it means the applets in it can grow only in the vertical or horizontal direction, so an applet with a high quantity of content can’t display everything it would want…

In past releases of KDE4 the right behaviour of applets was still not really finished, so some applets like the device notifier were more kind to the panel, displaying the whole device list on the desktop and an icon+popup on the panel, other applets like the twitter applet hmm not soo good 🙂

Now with KDE 4.2 every standard applet distributed with kdewill fully use the form factor concept, so far we have 3 different classes of applets:

Applets that are just the same or with very little differences in different form factors, like simple icons or the taskbar.

Applets that diminishes their information quantity in horizontal or vertical form factors, here are two examples:
when in the panel the now playing applet just displays the control buttons, and the leave note applet switches to an horizontal layout, so it makes enough room for an horizontal panel.

Form factors

Some other applets, like the device notifier or kickoff wouldn’t mean that much without some of its contents, so in the panel will be an icon+popup and in the desktop the whole plasmoid will be shown. but what about very big panels, so big that the whole plasmoid could fit and a ginormous icon wouldn’t make so much sense?

OGG version

When the applet knows that it would fit into the panel, the icon goes away and the whole applet content is displayed, and goes back to an icon when the panel is shrinked again.

Now, since Plasma in KDE 4.2 supports also panels not always on top and autohide panels, you could have for instance a thing that looks like a Quake console with plasmoids in it, just like Konsole for terminals 🙂

Painless Drop

Software

Just a little thing, but it looked to me it kinda deserved a really short screencast 🙂
Adding applets to the panel with drag and drop in plasma was a bit of a pita, because you had to hit exactly that 4 pixels between an item and the other, so painful that wasn’t really obvious it was possible at all…
so here is how the current trunk behaves 🙂


Ogg version

In other news some days ago something like 7 applets (did i forgot some others?:) were merged for 4.2 release counting what is in the workspace module and in the addons module, so there will be a ton more stuff to play with :).

That’s the reason for the kabooms we are fixing right now, but no fear 🙂

Tabbed plasming

Software

Quick video: this is a proof of concept plasmoid i wrote quite some time ago and then forgotten to talk about 🙂
Is a little tabbar meant to be put in a panel that lists all your desktop activities and lets you switch them in a quick way, as seen in the video it also keeps itself syncronized if something changes, so if you switch with the zoom user interface it switches accordingly, it creates and remove tabs when desktops are created or removed.

The name of the tab is the name of the activity you can set in the desktop wallpaper/theme/etc configuration dialog.
The name it’s just the beginning of the activity concept, in the future the desktops and the applets in it will be aware and will react to their context, like what time is it, is the network attached or not, heck even what is our geographic coordinate…
But that’s another and more exciting story that just a teeeny tab bar :p


Ogg theora version

Handle things with style

BlaBla

Did some work on the code of that little tiny things that lets you move and configure the Plasma applets, the poor ol’applet handles that really needed some visual love(tm) and some speedups, so the result is the following:

KDE 4.2 applet handles

It’s started from a Nuno mockup he did quite some time ago, and while the graphics will probably be a lot more refined than they are now (i.e. become closer to the mockup), i think code wise we are definitely here 🙂

First of all the old icons were so-so, partly because we didn’t have the exactly right metaphore partly because they eren’t designed for that kind of background, so now they are Plasma-theme specific, the default is a set of very simple monocrome shapes but more recognizable. In the future these little thingies will be used all across Plasma, so more power to theme creators, yay 🙂

Now the handle also uses a svg background from the plasma theme, it behaves differently (so always in the right way i hope:) for different types and sizes of applets and has a new cute sliding animation that makes the thing to feel more “attached” to the applet itself.

And now in youtube-o-vision:

But you prefer Ogg-o-vision, don’tyou? 🙂