Development

Akademy: KWin scripting

An effort to make KWin, KDE's window manager, more flexible, goes back more than two years, but it is now bearing fruit. Adding scripting support so that less technical users can make changes to the behavior and appearance of KDE without having to resort to C++ is now possible. KWin hacker Martin Gräßlin talked about the history and status of KWin scripting on July 1 at Akademy.

Some history

The idea of KWin scripting goes back to the Tokamak IV sprint in February 2010. The intent is to make the window rules more flexible. At that time, KWin rules were static and there was no way to say "I want all GIMP windows to go to a certain virtual desktop", for example. Gräßlin discussed the idea with Nuno Pinheiro, who leads the Oxygen theme project, at Akademy 2010, with Pinheiro making it clear that not requiring C++ was important.

A 2010 Google Summer of Code project added scripting support to KWin, but it suffered from a number of drawbacks. The API was hand-crafted and the documentation was hand-written. In addition, it "interweaved" the scripting and KWin core components in undesirable ways. It was, Gräßlin said, a prototype and one that should never have been merged.

One thing that was needed to support scripting is a generic animation effect. Previously, code was copied into many places to do the same kinds of effects for window state changes (e.g. window close or minimize). That meant that bugs got copied as well. A base implementation for window effects was added to react on state changes. That implementation is now made available for use in scripts.

Supporting a touch-based interface like KDE's Plasma Active was a "completely new world to us as a window manager", he said. KWin was highly mouse and keyboard-driven, which is not suitable for touch interfaces. Also, Plasma Active needs windows to always start maximized, which was a big difference. KWin started off supporting Plasma Active using ifdefs, but that became unwieldy. What was needed was a way to put a new interface on top of KWin without changing the core.

KWin changes

The window switcher is one place where scripting has come into play. Window switching is "surprisingly complicated" because there can't be one UI that fits all users, Gräßlin said. If there are just a few windows, there can be a simpler UI, but for ten windows the UI can't be the same. Since KDE 4.8, window switching can be scripted using QML, a JavaScript-based scripting language. There are methods to render thumbnails of the active windows and different use cases can use different layouts.

The same goes for desktop switching. It uses the same framework as the window switching support and will be able to be scripted using QML in KDE 4.9. Right now there is only layout available, as it is "not a focus" for the KWin project, but more could be added.

Support for QtScript, another JavaScript-based language, has been added for KWin as well. Those scripts can access all of the KWin options and client programs are exported to the scripts. Using D-Bus, scripts can be loaded and unloaded at runtime. Scripts can also call D-Bus methods and have their own configuration values.

Effects scripts can be written based on the AnimationEffect class. The scripts are written in QtScript, with an API that is similar to that of the KWin scripts. Instead of accessing clients, though, the effects scripts access windows. There is "no impact on performance", Gräßlin said, because no JavaScript is executed while rendering. In addition, window decorations in KWin have been rewritten in QML. That gives better performance, while allowing things like interactive previews of themes.

The KWin team likes to eat its own dog food, but that was difficult with the prototype scripting implementation. Most of the team did not know how to use the prototype. The newer scripting support is better understood, so the team is using it to find and fix bugs early on.

For KDE 4.9, several effects were ported from C++ to QML, including the "fade" and "fade desktop" effects. There are more effects to be done, and that is worth doing because 300 lines of C++ can be replaced with 20 lines of JavaScript, he said. He encourages other developers to work on this porting effort.

KWin is preparing to support Wayland by adding client properties to its API. These QProperties describe the client interface so that non-X clients can be handled. That means there will be one code base that can handle both window manager and compositing modes.

Multi-screen handling has also been changed substantially. There used to be lots of options governing the behavior of windows on multiple screens for historic reasons, but those have all been replaced. Now there is a single script for the only sensible choice: a video wall spanning all the screens. Other use cases could be scripted if needed, he said.

Scripting much of the functionality that used to be done in C++ has had a dramatic effect on the code size. KWin lost 5000 lines of C++, which was replaced with a few hundred lines of QML, Gräßlin said.

Third parties

Various third parties have started using KWin scripting. Get Hot New Stuff, the freedesktop.org project for sharing desktop resources, is using KWin scripts. A project to do window tiling for KWin exists as well. A tiling window manager struck some in the audience as rather amusing, but the implementation is working quite well and is not something that could have been done with C++, he said.

The "most impressive" user of KWin scripting is the Arctos Dashboard. It gives an overview of the open windows, has a KRunner interface, and an activity switcher. The developer has been collaborating with the KWin team and it has been a nice experience to have someone outside the project using and testing the scripting support, he said.

There may be other projects interested in KWin, beyond just KDE's Plasma. Razor-qt is interested, and Unity may want KWin because there are problems with its window manager (Compiz), he said. KWin has lost its static Plasma dependencies as they have been moved to runtime. There are still a few dependencies on kdelibs, but KWin could move to Qt-only in the future now that some KDE functionality is moving down into Qt.

Down the road, there are plans for integrating scripting with PlasMate, a development environment for creating Plasma widgets, themes, and more. There is a GSoC project underway to do that. Support for desktop thumbnails (e.g. for desktop switching) is already working though there are a few "glitches" with OpenGL rendering that need to be worked out.

Adding the ability to do unit testing with scripts is also in the works. Unit testing window managers has traditionally been difficult, so being able to inject test scripts simulating user interaction into a running KWin instance will be quite useful. Gräßlin said he is "really looking forward to that" as it will lead to a better tested code base for KDE 4.10 and 4.11.

The KWin team is looking for more people to try out the scripting additions and report on problems that they find. In addition, they are interested in hearing about use cases that they haven't thought about. It is "really easy to add things" and the team is open to new ideas, he said, so "give it a try". Scripting support has simplified KWin while also providing new capabilities; more input and testing can only help to make it better.

[ The author would like to thank KDE e.V. for travel assistance to Tallinn for Akademy. ]

Comments (none posted)

Quote of the week

— Scott James Remnant

Comments (6 posted)

GNOME 3.5.3 development release

GNOME 3.5.3 is now available. This development release marks the debut of a new API for Evolution Data Server, plus the project promises that "as developer you'll enjoy new widgets from GTK+ (GtkSearchEntry and GtkMenuButton), as user you'll delight the new Empathy interface, in a pure GNOME3-ish style." Nevertheless, this is a development snapshot release not intended for daily usage, despite the enjoyment and delight.

Full Story (comments: none)

Galaxy in-memory data grid released

Parallel Universe has announced the release of its Galaxy distributed memory system under the Lesser GPL. "What makes Galaxy different from other IMDGs is the way it assigns data items to cluster node. Instead of sharding the data on one of the keys using a consistent hashing scheme, Galaxy dynamically moves objects from one node to another as needed using a cache-coherence protocol similar to that found in CPUs. This makes Galaxy suitable for applications with predictable data access patterns, i.e. applications where the data items behave according to some proximity metric, and items that are 'closer' together are more likely to be accessed together than items that are 'far' apart."

Comments (27 posted)

Open Font Library Release 0.5

The Open Font Library project has rolled out release 0.5, tagged "Calling All Translators and Typophiles." The site hosts open fonts and serves web fonts via CSS; this version adds "an online translation tool which allows volunteers to improve language support" and the first release of a documentation push to create an online open font development guidebook.

Full Story (comments: none)

Version 5.3.0 of the Linux Libertine OS Font Family

Version 5.3.0 of the Linux Libertine font family is now available. This release includes a brand new face, Libertine Mono, in addition to the existing Libertine and Biolinium. Libertine Mono is a monospaced font suitable for terminal or development usage that matches the Libertine serif face stylistically.

Full Story (comments: none)

Development newsletters from the last week

• Caml Weekly News (July 10)
• What's cooking in git.git (July 9)
• Haskell Weekly News (July 5)
• Perl Weekly (July 9)
• PostgreSQL Weekly News (July 8)
• Ruby Weekly (July 5)

Comments (none posted)

Baker: Thunderbird: Stability and Community Innovation

Lizard wrangler Mitchell Baker reports on the future of Thunderbird. "Once again we’ve been asking the question: is Thunderbird a likely source of innovation and of leadership in today’s Internet life? Or is Thunderbird already pretty much what its users want and mostly needs some on-going maintenance? Much of Mozilla’s leadership — including that of the Thunderbird team — has come to the conclusion that on-going stability is the most important thing, and that continued innovation in Thunderbird is not a priority for Mozilla’s product efforts... As a result, the Thunderbird team has developed a plan that provides both stability for Thunderbird’s current state and allows the Thunderbird community to innovate if it chooses."

Comments (12 posted)

DiCarlo: Everybody hates Firefox updates

Mozilla's Jono DiCarlo writes on his personal blog about the consistent complaints he hears from users about Firefox's new rapid release process. "Of course nobody says "rapid release process" because people don't know that's what it was called. They might start out complaining about version numbers, or some plugin that doesn't work right, but when I ask enough questions to get to the root of the problem, it's always the rapid release process." The intrusiveness of the update process has driven users to Chrome, he says, and is a departure from Firefox's previous users-first mantras. "This isn't 'Firefox answers to nobody but you', it's 'Firefox answers to nothing but Mozilla's arbitrary six-week update schedule.' "

Comments (97 posted)

Total bankers: Twitter and LinkedIn's cynical API play (The Register)

Writing at The Register, Matt Asay takes a critical look at the business of open APIs, arguing that recent events with Twitter, LinkedIn, and Netflix highlight the dangers of building a product or business on someone else's API. "I don't know if there's a real shift in how the tech world treats its customers, but the API opportunism that is currently en vogue will likely lead to developers mistrusting open APIs and rolling their own services from the ground up, end to end." Is the solution, he asks, "an Open Source Definition for APIs and platforms"?

Comments (8 posted)

Yaghmour: Extending Android's HAL

Karim Yaghmour has posted a brief tutorial on how to add new device support to Android. "Contrary to standard 'vanilla Linux', Android requires more than just proper device drivers to function on hardware. It in fact defines a new Hardware Abstraction Layer (HAL) which defines an API for each type of hardware supported by Android's core. In order for an ODM's hardware to properly interface with Android, it must provide a hardware 'module' (unrelated to kernel modules) which conforms to the API specified for that type of hardware. This blog shows you how to extend Android's HAL by adding your own new type hardware to the Android stack."

Comments (43 posted)