Plasmoids in windows

Since forever (where we define the start of time to be when I started working on Plasma) it has been possible to run Plasmoids, or any widget that Plasma can display, in a window on its own using plasmoidviewer. It isn't completely satisfactory for running widgets in a window, though, because at its heart plasmoidviewer is a development tool meant for testing and debugging Plasmoids.

(By the way, did you know that there are similar apps for DataEngines and Wallpapers? plasmaengineexplorer and plasmawallpaperviewer.)

Marco worked up a small proof-of-concept app in playground some time ago that lets us run Plasmoids in windows slightly more satisfactorily. Here's a shot of a clock and the microblogging Plasmoids running with a Konversation window in behind and the pretty KRuner window nearby:

Right clicking on a Plasmoid gets you the usual suspects in the context menu along with a "Quit" entry that quits that Plasmoid. What's really cool is that they all run in the same process, keeping overhead down. Now, the goal for this isn't just to allow us to run Plasmoids in random windows on the desktop, but to provide an infrastructure for running Plasmoids full screen with Plasma Mobile in a way that is resource friendly but which also keeps the apps away from the main UI.

You can move the Plasmoids around, run them with or without a window border and background and more. It is currently in kdereview, and I'm busy polishing this up for 4.5. The name of this little wonder? plasma-windowed.

It currently knows about the following command line flags: -b, --border or --noborder to control the window borders (default is to have borders), -f and --fulscreen which starts the app fullscreen. This is just the start (it's only 368 LOC right now), however, and I have lots of ideas on how to make this even spiffier. :)

Now we can show Plasmoids on the desktop, in panels, on a dashboard, on a mobile device, on a netbook, on a screensaver, floating about and in Amarok. Soonish we'll have them on KDM, Kontact, Skrooge and KDevelop, too. Woo!

system tray progress

We've been slowly working away at getting the system tray in order. The goal is deceptively simple: allow us to host the entries there in a way that meshes with the rest of the user interface. It's actually been fairly complex due not only to the large number of existing applications that use (or, in many cases, abuse) the system tray, but because "meshes with" mean that the presentation and the interaction choices need to be done by the system tray. In the past it's been the application that has been in control of this, leading to utter chaos. With the new D-Bus based system, which has been picked up by some distributors for GNOME as well (in particular Canonical), we are now free to show the system tray entries they way we want to. It's been a long road, and we're finally coming to the last few steps in it.

We also made the design decision to allow notifications to be hosted by the system tray applet. That has changed somewhat: the notifications agent is now a stand-alone Plasmoid, so you can put it anywhere you wish. By default, it lives with other items in the system tray, which is sort of a panel-in-a-panel (or a panel-on-the-desktop if you use it there). We've been working on making that more elegant for 4.5 as well.

Here is my system tray as of today's build of what will one day be KDE 4.5:

You may notice two things immediately: the icons have changed in both appearance and ordering. We're still experimenting with all of this, and any of it may change at a later point. For instance, I think it's likely that we'll end up changing the technical implementation of the how the new icons are sourced slightly. So, it's a work progress; please keep that in mind as we continue on here. :)

As for ordering, we're experimenting with putting the "most important" entries on the left of the system tray and the least important ones on the right. While this feels "good" visually and makes sense from a reading order POV, we're still unsure whether it's the "best order" due to the possibility of icons moving around in a way that increases the likelihood of changing the order of the "most important" icons on the left. We'll see.

In any case, entries can label themselves with a status, such as "Active" or "NeedsAttention". Both Plasmoids and the new system tray protocol items can do this, and the system tray Plasmoid listens up for these changes and arranges the icons accordingly.

It also groups icons according to type: application icons are kept together, hardware icons are kept together, messaging icons are kept together ... This reduces some of the chaos. With the advent of the menus being client side, something Aurélien Gâteau contributed as part of his work for Canonical, we may end up booting out the application entries from the system tray in the 4.6 release (we likely don't have time to experiment with this for 4.5, sadly) and instead host them in the task bar along with their windows. Towards that end, we have a new DataEngine for status notifiers contributed by Matthieu Gallien (with some code borrowed from other works by Marco and Alain Boyer in the mix), which will make this quite a bit easier.

The non-application icons are also losing their colorful nature and becoming easy to see and understand glyphs. The battery Plasmoid also doesn't save extra space for itself for the on-hover display of battery power. Tooltip hovering is consistent as well. I can now swipe my mouse across the tray and quite easily and quickly see the status of my battery, internet, sound, screen and more in an attractive manner.

The "more icons" arrow has moved to the right as well and now opens a window with all the entries in them, looking all Plasmalike. This prevents rearranging everything on the panel (or simply running out of space on small panels!) when expanding the system tray.

The information icon for notifications and job progress has also been toned down. Not only that, but it has been augmented with a number of nice animations and state transitions to communicate what's happening. For instance, when a notification comes in, it smoothly animates between the unobtrusive "empty" icon and a full coloured one (blue by default):

The transition is very smooth (hello, QtKinetic and Plasma Animations!) and while eye-catching isn't vulgar during its movement either. Another case where it moves is when one or more jobs are in progress, such as downloads. When they first get started, it shows the new (well, to Plasma, you may recognize it from other places :) busy animation along with a count of active jobs:

I caught it at a poor moment and so the snapshot looks worse than it tends to in practice. (Yes, I was too lazy to do a screencast today. :P) What's really cool is that it starts to fill up pie chart style as the jobs progresses:

Clicking on the icon expands to a fuller job information view, with multiple jobs showing in a scrolling view so that they don't eat up the screen anymore. Same for notifications, by the way! Clicking on the icon again will make all the information hide and you can just watch the icon slowly fill up, at which point you get a very stylish notification letting you know what was finished along with a link to click to open it and a button to copy the destination with.

There are also fewer lines, backgrounds and what not in the default theme for the system tray for 4.5. Other themes are still able to do so, of course, thanks to the Plasma theming system, but we're aiming for a less-is-more elegance on the visuals.

Between the better visuals, the nicer interaction, the increased interoperability (e.g. Gtk+ apps that use the DBus Status Notifier system will appear 100% natively rendered in Plasma Desktop and Netbook!), I'm really happy with how it is shaping up. We still have some more icons to do (you can see krandrtray's blue monitor there still, for instance) and there is work left to be done to integrate the status notifiers into the taskbar, but we're getting there step by step, release by release and the results are very satisfying in day-to-day usage. It feels good, it looks elegant and it lets me do what I want and need to. :)

Plasma and Google Summer o' Code

Yes, this is the now customary "we have students in GSoC for our project" posting for Plasma. First, though, some updates on the scripting session from yesterday: Jonathan Riddel has posted logs of the meeting (thanks Jonathan! :); I've updated the documentation on Techbase for the Plasma Shell Scripting and review is welcome as are fixes made directly to the page, it is a wiki after all!

Back to the topic at hand, however: GSoC and Plasma! It's a bit of a different kind of year for us with GSoC, to be honest. In past years we've had a number of "brand new ideas being implemented from scratch" type projects. This year there's a much strong focus on finishing out features.

We tend to design a little bit ahead of ourselves so that we know where we are trying to go and always know what there is to do next when we finish what we're currently busy with. While this can sometimes lead to a feeling like we're constantly "behind" where we want to be (a sort of mental "optical illusion" :), it's quite useful for times like GSoC where it gives students lots of material to aim for. For instance, Diego Casella will be working on implementing the authentication framework for add-ons such as Plasmoids that are sent over the network. This will end up impacting, and improving, things like GHNS as well as remote widgets, and is something we did most of the design work for last year. I'm really excited to see this multi-level trust system go into play to help close that cycle for remote content in Plasma.

Brian Pritchett will be working on transparent caching for DataEngines and Plasmoids, which means that when you first log in (or if you lose network or start where there is no network) you won't be faced with a bunch of dead Plasmoids that aren't showing anything. Instead you'll be able to see whatever the last information retrieved was. Once new data comes in, the cached information will get dropped and things will start updating live again. This will have a huge impact on the perceived performance as well as the basic usefulness of the increasingly connected set of Plasmoids such as weather, microblogging, knowledgebase, open desktop, etc, etc. Due to the DataEngine infrastructure, Brian should be able to add this feature with little to no changes being made in DataEngine plugins and probably zero changes to the Plasmoids themselves. Awesome.

Yuen Hoe Lim wil be working on the mobile system tray, which aims to take our currently system tray widget and rework it for use in mobile situations. That means something that is finger friendly and works well on a screen with fewer pixels to spare. If that sounds like a contradiction in requirements, you've just understood why this will be such an interesting and challenging project.

Onur-Hayri Bakici will be working on Plasma Media Center (PMC) which has recently been gaining more developer attention and going at a reasonable clip again. Onur will be focusing on the media backends and API for the media browser, which is a central piece of PMC. Current work on PMC has been focused on using Qt's state machine framework to drive the user interface transitions between different media center screens (home, browse different media types, play different media types) while keeping the control pieces that travel between all screens such "jump icons" to open media or play/pause of playing media while browsing. Onur-Hayri's work should compliment this nicely by providing much needed work on the central content area that the state machine driven components "dance around". What's really neat is that a past GSoC'er, Alessandro, will be his mentor. Full circle, baby!

So we have something mobile, something media and two core infrastructure projects. From there it gets really interesting for Plasma: the rest of the Plasma related projects aren't focused on the Plasma Workspace shells or Plasma core infrastructure. Instead, they are projects to integrate Plasma into other applications.

Ryan Rix and Siddharth Sharma are both working on "summary page" implementations using libplasma. Ryan is bringing a facelift to Kontact's aging summary page while Siddharth is providing a dashboard style overview for your finances in Skrooge. Both projects will be using libplasma through a KPart that combines the newspaper view we know from Plasma Netbook with a ready-set-go assembly that hosts it all. Ryan and Siddharth are working on the KPart together since they both need it, and this will likely end up in kdebase-runtime so any application can get to it easily. That means that a Plasma based dashboard which allows an app to use Plasmoids for summary screens, overviews, dashboards, etc. will just a few lines of code away. It means bringing together Plasma with one of KDE's great technologies that debuted back in KDE 2: KParts. It's an interesting thought: bringing together two strong component technologies like that. It may also end up using the Javascript scripting for control as Plasma Desktop and Netbook now do, and it will certainly open up writing plugins for apps in Javascript and C++ for free as well. Getting a good first set of such plugins will constitute the bulk of Ryan's and Siddharth's projects.

Shaun Reich is going to be working on bringing Plasma to the log-in process with a Plasma based KDM frontend. The existing front-ends will remain, but with the Plasma presentation layer KDM will gain theming unity with the Plasma workspaces and access to much more modern visual capabilities but, much more importantly, it will gain support for things such as on-screen keyboards. By using Plasmoids for the KDM layout, not only can the log in portions look and work nicer, but KDM will instantly get access to all kinds of applicable plugins. Imagine being able to mute the music playing in the background from the log-in screen, leaving notes for others or being able to log in when there is no physical keyboard.

There is also a project, taken on by Shantanu Tushar Jha, to create a bridge between Gluon and Plasma by making a Plasmoid that plays Gluon creations. I wonder if this could make Gluon our answer to game development with Plasma Mobile?

This outward integration of libplasma into applications where it makes sense is a beautiful next step in taking advantage of all the hard work we've done on the core infrastructure. Besides consistency, it's also going to bring increased productivity to our developers. For instance, with GSoC yet to officially start, Ryan and Siddharth already have the KPart nearly functional.

There are other KDE GSoC projects which will impact Plasma as well, such as Jure Repinc's project to improve handling of multiple monitors in Kephal. Kephal is used by most of the components in kdebase-workspace for things related to screen management, so improving this will have a huge positive impact on users of KDE Plasma Workspaces who have multiple screens to work (or, as the case may be, contend) with. Another project with implications for Plasma is Paulo Romano's work on UPnP support in Solid, and I'll be keeping an eye on the various Nepomuk related projects as we're starting to use Nepomuk more in Plasma as well. (More on that in a later blog though.) The work on KWin that is set to happen in this year's GSoC will also impact us positively as keeping the window manager moving has been a critical part of making Plasma Desktop better and better with each release.

So it's going to be an interesting summer with lots going on in Plasma, and even more in the general KDE landscape. Bring it on! :)

plasma shell scripting

It's been a ridiculously busy few weeks during which I haven't had much time to write and keep everyone up to speed on what's up and going on (let alone some of the other writing chores I have on my plate right now). Let's see if I can't get everyone caught up over the next few days though, starting with this blog entry.

Today I held a tutorial in #plasma on irc.freenode.net aimed primarily at KDE packagers about the Plasma Desktop Scripting framework. I felt this was an important topic to do some downstream communication on since it's become central to how plasma-desktop handles initial setup, updates and things like layout templates. While plasma-desktop has supported this feature since the 4.4 release, there are a lot of new features in 4.5, it's taken on a more central role and some of our downstreams managed to get things Very Wrong(tm) with their scripts in 4.4. So I was very happy to see that several distros were represented by those who turned out. I should also tip the hat to Jonathan Riddel for organizing the time and announcing it on the KDE Packagers mailing list.

Hopefully someone will post a cleaned-up version of the log from that session as it was very informative and lots of great questions were asked and answered. We'll see, I suppose. :)

There was also a feature request part of the tutorial right at the end. (See, this is why you want to attend when its announced on the mailing lists! ;) A total of nine additions to the API were requested, and all of them have been implemented in the hours following the meeting.

I look forward to seeing what our various downstreams will be able to do with this powerful new tool. There were some great ideas about how to address various management issues floated, such as how this opens up the possibility of handling Plasmoids that have a bug, but only in a specific version of them. It's really interesting to see the possibilities that open up when we give the power of a scripting language to people. :)

It's such a great tool, actually, that I spent some time last month extracting the scripting from plasma-desktop and putting it into libplasmagenericshell. This means that in 4.5 Plasma Netbook will also sport the same javascript API (though not the interactive console) and when the Plasma front end for KDM is completed it will support it as well.

come together

Reading planet.kde.org the last few days has been great. There have been several great blogs about akademy.br, a regional Brazilian KDE event that kicked off this year with its first installment. It looks like they did a great job with it and I can't wait to see next year's event. The number (and quality!) of regional KDE events just keeps growing: Akademy.es, Camp KDE, Akademy.br. This is an interesting evolution from KDE only participating as part of other conferences (something we still do, believe in and get a lot out of), through to Akademy growing up as our own themed conference to an increasing number of KDE specific events around the globe.

This reflects the growing efforts in KDE itself, I think, something that can also be seen on planet.kde.org. Frank updated us on the progress ownCloud is making to free the cloud for all, Roozbeh wrote up a bit on Chakra Mini which is yet another Plasma Netbook based offering and Marco showcased the work of Bjorn Ruberg on the Plasma On-Screen Keyboard complete with a video of it running on two different devices:


OGG video version

This is really all just tip-of-the-iceberg stuff, as you might imagine. There's work underway to provide a Plasma front end for KDM, for instance. The most interesting thing for me in all of that (besides standardizing look and feel and the generally neat things we'll be able to do with it visually) is that KDM will get things like that on-screen keyboard for free. This is the kind of stuff people had to hack into KDM in the past (and did, in some cases!), but which we'll now be able to say is just part of the standard kit. This is also an interesting example of how different hardware formfactors (in this case touch and mobile in Plasma workspaces) are helping drive improvements elsewhere as well (in this case accessibility in KDM).

Another interesting example of this is work being done to streamline the KDE Development Platform for non-desktop scenarios that finally made it's way out of the KDE Maemo (should that be Meego now?) team onto kde-core-devel with this email from Kevin Ottens a couple days ago. Everyone will benefit from people casting a critical eye on this key shared set of technologies.

There is so much more like that going on around KDE. We don't always do the best job communicating it out as many of us are busy and having too much fun working on these things, and sometimes the communication side of it gets less priority than our users and downstreams probably would wish for. :)

Still, the KDE steamrollers continue on paving the way forward for all of us who rely, or would like to rely, on Free software on all our computing systems. Efforts to coordinate that energy even more effectively are underway and ongoing and we have so many exciting challenges ahead of us (including really "simple" but actually difficult ones like, "How do we improve our documentation?") that I don't see it getting boring any time soon.

solving a little problem with a slightly bigger solution

More than once we've received tales of woe about how someone removed the panel accidentally and then either couldn't or had a hard time getting it back to a nice default. With Kicker, I never had this problem because you couldn't remove the default panel: you were just stuck with it, love it or despise it. There were many requests to address this issue in various ways, and in doing so with plasma-desktop it has resulted in this new kind of problem. Yes, even with a confirmation dialog. Fair enough, it needed to be improved further.

First, I defined a Plasma::PackageStructure for layout templates. So now with a zip file or a directory tree with contents/layout.js and a .desktop file we could list and find layout templates on the system. A layout template is basically just a bunch of Javascript that creates panels, activities, widgets, etc. A template can be associated with a given Plasma shell (e.g. plasma-desktop) and advertise what kind of containment it creates (e.g. a panel of some sort). So far, with all 4 lines of actual code involved it wasn't too exciting, but I could start to smell success down the hall.

So next I made it possible to load a layout template from a Javascript run via the Plasma desktop scripting support. So now you can do something like "loadLayout('org.kde.plasma-desktop.defaultPanel')" and it will load the template (if it exists) for the default panel. So now such scripts can call any template by name that is installed, allowing these scripts to become a bit more modular if desired. This still wasn't quite the needed solution, but while working on that I did implement persistence in the desktop scripting console so you can close/open it and whatever was in there last will be in there again the next time you start it. While nice, this was even more irrelevant to the problem of getting back your default panel if you terminate it.

Then I tore out the hard-coded default layout in plasma-desktop and re-wrote it using a Javascript run on first start due to being installed into share/apps/plasma-desktop/init/. This new script makes a loadLayout call to load the default panel template, and so I made such a template and set that to be installed as well. This dropped a few dozen lines of C++ and turned them into about half as many lines of Javascript.

The final piece was to alter the Add Panel action so that it was aware of templates. This means that you now get this when you right click:

That "Default Panel" entry does what you'd expect it to, and whenever we (or our downstreams) change what the default panel layout is then it changes, too, because both the init script and the context menu action trigger the same layout.

This also means you can create your own customized layouts. Which means one could even implement a "save this panel as a template" feature. It would also be feasible to add a "close this panel, but save it for easy restoration later" without too much effort. We could even GetHotNewStuff those panel layouts. We could provide the same functionality in the upcoming Activity Switcher for the desktop layer. Some of these "could"s will likely happen for 4.5, though I'm not sure exactly which ones yet as I'm now off to making the desktop toolbox a little less craptastic, as it's up next on the "to polish" rotation.

one team, two teams! small team, big team!

From time to time I hear things to the effect of, "It's hard to get anything done in KDE. Where's the project-wide direction and management?" Indeed, it's not trivial. We could try to excuse the issue and say, "Well, KDE is huge now. 600+ developers contributing to the last release, even more translators, artists and others. That's a lot of people to move about!" While this is true, I don't think it is the whole picture.

In the beginning, some 14+ years ago, "KDE" was a software project to create the "Kool Desktop Environment" (quickly becoming the "K Desktop Environment"). There were a little over a dozen contributors and they all knew each other as a result. It was an ambitious project given how much software they planned on writing, and the results of the first go-around (KDE 1.x) were impressive though certainly small compared to what KDE (which now refers to a community rather than a specific project) puts out today.

Over the years, from that one team sprouted dozens of others. Each of these teams works very similarly to how that first group did: a generally meritocractic process of consensus based development held together by personal relationships. Each of these teams has a similarly strong send of purpose and tends to get things done. We call the sum total of all of them "KDE".

What didn't happen during the creation of all those teams, which was a purely organic and non-engineered process, was the creation of working bonds between the different teams. Sometimes they exist due to the people being involved in more than one (often over a period of time rather than concurrently), but many teams are fairly self-contained. This is not a bad thing, but it makes doing things "across all of KDE" more tricky.

In addition to this, the different teams have different interests and goals. In Plasma we are interested in things like mobile devices and media centers in addition to the desktop/netbook/tablet space. I'm not so sure the KDE Finance apps care much about media centers. I doubt the KDE Games people care that there's a use case difference between netbook and desktop: their stuff almost naturally works equally well in both cases, while the Plasma stuff required engineering efforts for that to happen!

A decade ago we had one set of goals and one group of people who knew each other marching towards them. Today we have a variety of (mutually supportive) goals and many groups of people who know each other marching towards different ones. This is the challenge to getting "global" vision.

What to do? In part, I think we need to drop the idea of getting "all of KDE" to all do the same thing all of the time. It is completely alright for just some of us to focus on mobile, for instance, while others focus on making great photo manipulation software for desktops and workstations. (To pick random examples out of the air. :)

We also need to realize that there are some things that we need "all of KDE" to coordinate on, otherwise they just don't work. The git migration (which is nearing the finish line at this point) and brand repositioning efforts are two obvious, if somewhat trivial, examples of this. They are not the only ones, however. To get those things done, we need to work on the bonds between the teams. We need to re-find our own KDE identity and put it into practice through personal relationships and work across team boundaries. We need to be able to go into shared efforts and not feel the need to henpeck each other just to prove that we're contributing in some way, or feel unease at other's (unknown) intentions because we don't really know those people very well personally.

In Plasma, we are trying to reach out more and more to other teams that are relevant to and interested in our efforts. This includes teams like KWin, Oxygen and Solid (we share goals) but also teams like Skrooge (we share needs). We also strive to tell our story to the rest of KDE so "you all" know what "we all" are up to. We have more to do, but it's a reasonable start. Each of us in each of the teams involved in this "are KDE", but through these cooperative efforts we help build personal relationships, create shared values, generate goals and spread expertise around.

In the coming days and years, if we can build more inter-team bonds then getting things done "in KDE" might be a lot easier and more successful. It may never be as easy as it was when Ettrich first started hacking on his Kool concept (koncept? ;), but that's a price of success. We can, however, make it not only possible to create more global vision more easily but actually do it, too.