Tag Archives: desktop

A Declaration of Plasma Love


Declarative RSS reader The image on the left is a new (example) plasmoid that marks an important change… this is going to be a quite massive blog post, with pretty technical details about what I think is going to be a feature of an higly important strategic relevance on the road towards Plasma as a mature and powerful platform.

The Plasma declarative bindings have landed into kdebase! This means it will be possible to use the new QML language part on Qt 4.7.

As Aaron noted some days ago, QML in conjunction with now in heavy development technologies like QtComponents (and in the future Qt cene-graph) will play a key role in the creation of user interfaces in the future, and gives us a very important puzzle piece we were still sorta missing.

So we deceided to be (as usual 😉 erly adopters of the technology and with the KDE Plasma workspace 4.6 the first pieces will be in place for the roadmap that will lead us basically to this path:

  • Separate the implementation of the logic from the user interface
  • Avoid C++ (and well, any imperative language) as much as possible for the UI
  • Be flexible, an application should be able to jump between different devices as easily as possible
  • do applications that can chose the proper ui amond different choiced depending on the device used, the screen size, the input methods and what not
  • With QtComponents, use what will be the native set of widgets/components for the given platform: on a MeeGo phone, use its own widgets, theme and UI paradigms, but a different interface somewhere else
  • Performance, perforance, performance, enter Qt scene graph

So, what will have the KDE Plasma platform 4.6 of all of this?

Use QML from C++ Plasma widgets

The first pass (needed to do the following one) is to have a way to easily load a QML file into a normal C++ plasmoid. Now, loading a QML file into a QGraphicsScene (and making it well behave inside the QGraphicsLayout based Plasma widgets) is a quite simple operation, however it is a bit long and repetitive amount of boilerplate code… enter Plasma::DeclarativeWidget.

This is a normal QGraphicsWidget just like the other Plasma widgets, all you have to do is to add it in the QGraphicsLayout of the applet, set the path of a QML file in it et voil

Small goodies


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

monochrome and blur

  1. 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
  2. Monochromatic icons support for systemtray icons that use the new shiny protocol (dependent from the Plasma theme)

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 🙂