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
talked about the history and status of KWin scripting on July 1 at Akademy.
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.
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.
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,
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,
In addition, window decorations in KWin have been rewritten in QML. That
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
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.
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
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
[ The author would like to thank KDE e.V. for travel assistance to Tallinn
for Akademy. ]
Comments (none posted)
"Without the ability to play around, mess about with the code without
consequences and privately on your own computer, you can’t be truly
creative with it; and if you’re not being creative, it isn’t fun!"
— Scott James Remnant
Comments (6 posted)
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)
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)
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
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)
Newsletters and articles
Comments (none posted)
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)
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)
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)
Karim Yaghmour has posted a brief
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)
Page editor: Nathan Willis
Next page: Announcements>>