KDE’s Plasma is heating up

If you visited the Plasma project’s outdated Web site in past weeks, you might have gotten the impression that the team behind the project to revitalize the KDE desktop hasn’t been up to much these past months. Delve into KDE’s SVN repository, mailing lists, or the mind of lead developer Aaron Seigo, however, and you’ll find a more exciting story.

KDE launched Plasma in 2005 to revitalize the desktop interface, which the project said had remained “essentially the same” as it was in 1984. The initiative sought to renovate the KDE desktop codebase for the upcoming KDE 4 release, as well as to make innovations to KDE 3’s conservative interface. Key goals included marrying the Kicker desktop panel, KDesktop root window, and SuperKaramba widget manager into a single Plasma interface; providing a framework to make widgets easier to write; making the unified components more consistent both visually and in terms of usability; and making the desktop a more organic workflow environment.

This month work will intensify on Plasma’s Zooming User Interface (ZUI), which is intended to shift the desktop’s purpose from a “file manager view” used to display a static set of icons to a dynamic, contextual project management tool. The ZUI can be understood as a sort of reimagining of the virtual desktop metaphor.

According to Seigo, “By zooming out, users can get an overview of all the object groupings that they have made. These groupings may reflect the projects they are working on, be ways to keep different sets of files organized, etc. By hovering or clicking on one of these groups when zoomed out, users can either get a preview/snapshot of what is in the grouping, or zoom in on that grouping so that it is displayed full size on the physical screen. Thus we can offer much greater flexibility on the desktop layers while giving users visual context. A lot of promising research was done into zooming intefaces by Jeff Raskin before his passing a few years back.”

The Plasma team will also implement panels, the malleable applet containers also known as “start bars” or “task bars,” and thereby outmode Kicker. The team will implement Kross scripting framework to allow developers to write Plasma desktop widgets, called Plasmoids, in JavaScript, Ruby, and Python. The team will continue to write new default Plasmoids, including a KMenu replacement. Expect a rapid clip of development to continue through to October, when KDE 4 is scheduled to be released with Plasma as an integral component.

A substantial amount of work has been completed on Plasma, and the project is in a usable state (at least for alpha testers), but a tremendous amount of coding remains before release. According to Seigo, 12,120 lines of code had been committed to the project as of June 20, including work done on the KRunner run dialog. He proudly notes a development pace of about 240 lines per day over the past few weeks. Additionally, “extensive” improvements have been made to SuperKaramba, which now exists as a library within Plasma.

To learn more about the changes being made for KDE 4, you can explore the first alpha release. Seigo notes that some of the newer Plasma code relies on functionality introduced in Qt 4.3, the newest version of the toolkit from which KDE is built, which was just released on May 30.

Seigo is working with a team of eight other core developers, as well as an unspecified number of extraneous widget and plugin developers. Their accomplishments to date generally fall into the planning and development of the following:

• The display canvas: The fundamental component of all Plasmoids, the canvas provides developers with a standardized framework for constructing GUIs. This functionality includes a full set of default widgets (the old-fashioned type like buttons and listboxes, not Plasmoids) and the ability to perform “arbitrary transformations” — graphical effects, including transitions courtesy of the Phase animation and effects class. It is built from Qt 4’s QGraphicsView class, which Seigo describes as “very capable and very impressive.”
• The data provisioning system: Plasmoids will often serve to visualize a specific “domain” to users; for instance, the machine’s hardware specifications, available storage devices, or movie reviews from a particular Web site. The data provisioning system will allow common back ends called DataEngines to be written for any Plasmoids accessing a given domain. This system is intended to spawn a more efficient developer community than exists for the present SuperKaramba, where widgets with very different styles and themes often access the same domain with only slightly different code.
• The support library: A boring, though fundamental, library that facilitates loading and managing plugins, handling Scalable Vector Graphics (SVG) elements, and Plasma theming. Widespread use of SVG for more attractive and zoomable interfaces will be a hallmark of Plasma, and the KDE 4 desktop in general.

Additionally, the Plasmagik packaging system has been merged into libplasma to provide users with single-click downloading, uploading, and management of Plasmoids. DataEngines and sample Plasmoids for Facebook, image viewing, online dictionaries, hardware notification, and weather resources have already been written. The team has also recently implemented a system for DataEngine configuration per-Plasmoid.

As it currently stands, Plasma is less resource-intensive than its KDE 3 counterparts. Though this is in part due to general performance improvements in the foundation of KDE 4 and the higher efficiency of newer versions of Qt, there is a resource-friendly ideology at play in the development of Plasma. The data provisioning system, for instance, will allow multiple running Plasmoids with overlapping functionality (a familiar scenario for SuperKaramba users) to pool resources. Additionally, by having graphical effects centralized in a common canvas, users will be able to configure visual complexity to suit the power or purpose of any host machine.

The APIs that Plasmoid developers will use to access the functionality of Plasma already exist and are being used by third-party developers writing DataEngines and widgets. They are still being expanded, and receive constant maintenance from Seigo and the Plasma team. Seigo expects any gaps in the present API them to be resolved by early July.

A variety of systems for displaying desktop widgets exist beyond KDE’s Plasma, but Seigo expresses only moderate interest in getting Plasma to interoperate with them. He says he would like to see support for loading HTML/CSS Mac OS X Dashboard widgets in Plasma, but not until after KDE 4 is released. Opera widgets may receive a similar treatment. He does not addresses the bevy of other widget systems from GNOME, Microsoft, Yahoo!, and others. Of course, present SuperKaramba widgets will continue to work with Plasma for KDE 4 under legacy support.

Seigo gives good reasoning for spurning other widget systems, even though they’re a potential gold mine of existing content. Plasmoids have advantages over many other widget systems, including SVG theming that will make Plasmoids more scalable and attractive, and the DataEngine system that should make Plasmoids easier to develop. He hopes that with the tools and available languages that serve to ease the job of Plasmoid developers and broaden the functionality of their creations, “it will [not] take the vibrant KDE community [long] to come up with equivalents for pretty much any widget out there.”

Both DataEngines and Plasmoids can be developed quickly with the Plasma framework. Seigo notes that the dictionary DataEngine took only 81 lines of code, while a more complex one for weather took 373. Both of these DataEngines will likely be reused in several Plasmoids. The current dictionary Plasmoid occupies just 177 lines of code.

Work will continue on Plasma past the initial release of KDE 4. Seigo has already identified several tasks for late 2007 and 2008, some of which are major feature additions. He would like to implement a full-fledged physics engine for “realistic object interaction” in Plasmoids and a networked collaboration framework to parallel the DataEngines system. He would like to see a Plasmoid Design Studio for burgeoning developers, and he has big plans for media center integration. Of course, more predictable goals will also be carried out, such as to create more DataEngines and Plasmoids, optimize performance, and integrate with KDE applications.

The last of those goals may have interesting consequences, such as “live objects,” as Seigo dubs them, which can be attached and removed from applications at will. He gives the example of dragging a contact off of a Kopete buddy list. Plasma would then render the contact’s icon and instant messenger status as an SVG image displayed on the desktop or on a layer of the ZUI, communicating with Kopete through DBUS calls embedded in the SVG XML. The user could then click on the contact to start a conversation.

The best resource for staying up to date with Plasma development is Aaron Seigo’s blog. For those looking to learn more about the evolution of Plasma, Seigo recommends demonstrative videos on YouTube. To try the latest features in Plasma for yourself, look for future alpha releases of KDE 4. If you would like to participate in Plasma development, consult the Get Involved with KDE page or the Plasma Techbase page.