Your Rough Guide to Plasma.

the default Plasma desktop in KDE 4.1-beta1.
So I’ve chosen to become

Shane’s Personal Plasma Steward
. This in turn makes me
much more aware of things, that I personally take for granted which aren’t so
natural (yet) to others. One of those things is “How does this thing work?” (for
“plasma” as value of thing). Let me explain on a high level how you can use
Plasma and make the most of it, starting with a default Plasma desktop.

Plasmoids and Containments

The essence of Plasma revolves around two basic concepts: Plasmoids and
Containments. Plasmoids are Applets, small applications that live on
the desktop. Containments are applets as well, they act as container for
Plasmoids. That’s it. Really. On a default desktop, there are two main elements:
the Panel and the desktop itself. Both are containments in the Plasma sense.

The Panel

The panel holds a couple of Plasmoids, starting from the left, there’s the
Kickoff application launcher. You can use it to start
applications, open recently opened files and the usual logout/shutdown options.
There’s also a structure that allows you to browse through your applications.
The layout has been optimized for the usecase that is most common: starting an
application. The default tab is the “Favorites” tab that holds you most-used
entries. In the beginning, you’ll probably find yourself using the Applications
tab more often. Once you have found out what your most frequently started
applications are, right click on the items and add them to your favorites (or
directly into the panel or on the desktop. Note that you need to “unlock” Plasma
by means of right clicking on the desktop for any kind of modification). If you
prefer KDE’s traditional menu-style application launcher, change it to use that
by right clicking on the menu button “Switch to Classic Menu Style”

The next icon (looking like either a desktop computer or a laptop, depending on
the type of machine) is the devicenotifier. Plug in a USB disk
and it will pop up a dialog that lets you open the device in Dolphin.

The next item on your panel is the pager. It allows you to
switch between your virtual desktops. If you change the layout of the pager
through the “number of rows” option, it will also affect the layout and
animations that are shown in KWin’s DesktopGrid effect —
(Switch on desktop effect, press [CTRL]+F8 to see it.) For bigger pagers
switching on “Display windows icons” on the pager makes sense.

The taskbar is up next on the panel. It shows an area for all
open windows on the current desktop by default. You can make it show all windows
by checking “Traverse Windows on all desktops”. Right clock on the window frame,
choose Window behaviour, find this option in the “Focus” dialog. KWin’s The
expose effect offers similar functionality, it lays out all windows on the
screen, start typing to filter the list, navigate with either mouse or arrow
keys. The size of the text on the taskbar items can be set in Systemsettings |
Appearance | Fonts | Taskbar.

Next on our default panel is the digital clock. This clock can
display the time in different timezones. The sizing of the clock is half
witchcraft, but you can partly influence it. The clock will adjust its font size
to the area it is given by the surrounding containment (that’s the panel in this
case). If you choose to display the date, this date will be rendered using the
“Small font” option from Systemsetting’s Font dialog. The time will take the
rest of the space. That means that for those who want it, it’s possible to screw
up the clock’s display. On the one hand, the clock has to obey the user’s
setting for Small font (this setting reflects the “smallest readable font”, by
its very own definition, it simply does not make sense to use fonts smaller than
that). So in the end, you’ll choose yourself the amount of information
displayed, and if that fits. If you want to display more information, make the
panel larger or put the clock on the desktop where it can grow freely.

The rightmost Plasmoid in the default panel holds the systray,
which is used by traditional applications as a dock. There’s not a lot to say
about it, other than “Plasma developers don’t like the systray for its archaic
architecture and want it to go away today rather than tomorrow”. You probably
know it from other desktop (even Operating Systems) already. It’s basically
a dumping ground for all kinds of things that you can better leave to their
own plasmoids.


If you have unlocked your desktop (you can do that by right clicking on the
desktop, or when no application has the focus with [CTRL]+L), a small Plasma
logo will appear in the bottom right corner (it’s commonly named the “cashew”).
Click on this cashew, and the panelcontroller opens. The panel controller allows
you to reposition, resize and realign the panel. The Plasmoids living in this
panel will adjust their size automatically. Plasmoids have basic knowledge about
sizing, provided by the containment. They’re programmed to take advantage of
that size, and inform the applet about how much space they possibly need. In the
end, the containment gives a possible size to the applets, the applets obey.

Adding Applets

Unlock the desktop and you’ll be able to add and remove Plasmoids from panel or
desktop. You add Plasmoids by simply dragging them where you want them. Right
click on an applet to remove it. The “Add Applets” dialog also allows you to
mark certain applets as “Favorite” so you can find them back more easily.
The “Install new widgets” button allows you to add widgets you’ve previously
downloaded. Currently it supports native “Plasmagik” packages and Mac OSX
dashboard widgets. Widgets you install this way can then be accessed just like
regular, preinstalled widgets.

The Desktop

The desktop is in fact another containment. One that doesn’t put size
constraints on the applets. Applets can be moved and sized freely. On the
unlocked desktop, Plasmoids will show a frame when you move the mouse over them.
This applet handle allows you to move, resize, relocate and realign the panel.
It also allows you to drag Plasmoids on the desktop. The buttons in the corner
are used to resize, rotate configure and remove the applet. When rotated, a
Plasmoid will act magnetic towards 12 o’clock, so it’s easy to get them back
into sensible position. By default, most applets keep their aspect ratio when
they’re being resized. If you want to freely resize an applet, hold the [CTRL]
key pressed while resizing.

Right clicking on the desktop also offers you to configure aspects such as the
wallpaper used, and the Plasma theme. Both actions offer to download new
wallpapers and themes through KNewStuff.

With open applications, it quickly gets hard to see the Plasmoids on your
desktop. The Dashboard gets those Plasmoids in front of you,
much like the “Show desktop” functionality you’re used to from traditional


KRunner is a versatile mini-commandline. You can use it to start applications,
open webpages, access bookmarks, search through your desktop data, calculate
short equations, and many more. Pressing [ALT]+F2 opens the Krunner dialog. You
just start typing and KRunner will start searching matches as soon as you’ve
entered more than two characters. You can open the settings dialogue to learn
about KRunner’s functionality, provided by plugins. You can navigate through the
matches using the tab and arrow keys.

If you want to know what’s going on on your system, there’s the “Show System
Activity” button, giving you quick access to a list of windows and processes,
with options to monitor their output and kill processes.

“Activities” or the Zooming User Interface (ZUI)

The desktop toolbox, accessed via the top right corner has a button for zooming
out. Plasma allows you to have more than one activity. Basically, that is
multiple desktop containments hosting multiple sets of Plasmoids. Zoom out from
your current activity, choose “Add activity” to create a new containment, zoom
in to your new containment and customize suiting your taste. Plasma’s zooming
and KWin’s desktopgrid are similar in that respect, but there is a fundamental
difference. While virtual desktop are used to group and organise windows,
Plasma’s activities are used to group and organise plasmoids. This way, you can
switch between activities and have relevant plasmoids supporting the task you’re
currently trying to accomplish. You can create a “Freetime” activity, with comic
strips, a puzzle and other Plasmoids, and a work activity, with relevant RSS
feeds, calculator and calendar.

That’s it. Hope some of you understand Plasma better now, and that this blog
helps those that feel lost initially do a little less so.

GTK themes are fine again.

Two days ago, I’ve blogged about
the environmental variable that sets the correct path to the GTK theme was
broken. This made GTK apps use the default theme, which looks rather clunky.
Yesterday, Kevin Kofler and Rex Dieter committed a fix for this
bug. Rocking, dude! :-)

Are we breathing in the same rhythm?

Tom and
discuss timing and release schedules, and development cycles. Aaron talks
about trunk/ and freezes therein should follow a natural lifecycle. This assumes that
the whole KDE community lives and breathes as one individual, synchronised and all.
So a development-and-release-cycle forces all developers into one rhythm. Everyone
has to follow this one release rhythm. It’s a good idea, but I think we should also
make the lives of those easier that choose another breathing ryhthm.
There are a couple of things to consider here. The most obvious being that we need this
flexibility anyway. We rely on certain release mechanisms and interface stability
policies in other projects as well. (We partly solve this problem by providing abstraction
layers, think phonon and solid). Now the interesting case is that Phonon, which is new in
Qt’s 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle
in Qt, and a 6 months one in KDE. So one could argue that it’s a smart idea to breathe
in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.

This does not solve the initial problem I think, which I think is “different parts
of KDE have different heartbeats”. Neither Tom nor Aaron have really
questioned the way we currently deal with SVN before
releases, so I’ll put on my shiny pink asbestos suit and do it.

What if we never froze trunk? Others (such as, incidentally
Qt) have no freezes in trunk/ and it seems to be a popular and well-working development
style for some. When a release enters a freeze, a branch is created that will
be stabilised towards the release. trunk/ at the same time stays open for feature
additions. The Golden Rule is “You don’t break trunk/ (this is what branches are for)”.

(For those not too intimate with development schedules of KDE: trunk/ is frozen
roughly 2 months in advance of a release (supposedly every 6 months). After the
actual release, trunk/ is opened again for new features. Features that take longer
than the allotted time be developed in a branch and moved into trunk/ “when
they’re ready, but not during freeze”.)

The obvious downside of this “It’s always summer in trunk” is that you need to
spend extra efforts to get people
to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more
discipline, and probably puts some extra weight on the shoulders of those who simply
care about good KDE releases. But as we all agree,
SVN sucks for branching and merging. So right now we make it hard for people to work
with different branches (stable/ and trunk/).
It would allow those that need more time to
do their thing to stay in sync with latest features. Basically, it would allow for
different rhythms in the community. As this community grows and becomes more diverse
this might pay off in the end.

New tools are on the horizon as well. Distributed version control systems allow
for a more flexible way of sharing code between peers.

The thing is that we cannot really choose, people are using git anyway. And after
having used it for a bit, and git-svn to interact with svn, I have to say that it
makes a lot of things much easier. For one, it doesn’t force the commit policy of
the project (“don’t break trunk” maybe ;-)) on yourself or your team, and it makes
it easy to share code with others. That might want to work one a feature (or some
surgery) together, but others (those that don’t want to be affected by this surgery
just want their desktop to work. Now imagine these peeps, just start developing
features by sharing a number of git trees and committing features to trunk/ when
they stabilise, i.e. presumably don’t cause regressions. It also nicely solves
another issue we had recently. Rafael needs some time to finish Goya (have it API
reviewed by Kevin ;-)), but Jeremy already wants to use this feature in
GetHotNewStuff2. Those three share a “review” branch, which is merged when
everyone’s happy (after having been announced on kde-core-devel. (Imagine
integration of some sort of peer review system, like review board with
this branch!). This development
style can partly be tested by a subproject, of course. This subproject can then
track trunk/ from SVN and develops features in a distributed way, probably with
another branch as master that sits on top of it and tracks. It’s not really a
technical problem, after all, the tools should support the natural way of
breathing for the community. For git in particular, I see the steep learning
curve as one of the major show-stoppers right now. It would, at this point
simply make the barrier of entering a project much higher, which is not a good
thing. With distributed source code management, the question “Which one is
the authoritative copy?” becomes a purely social thing. In the SVN case, it’s
always the SVN server, in the DVCS (OMG!) case, it’s “who you trust”, that
would be the version we publish via SVN.

Interestingly, the KDE’s Internationalisation people already work in a distributed
fashion. In the Netherlands for example, Rinse collects translations; that are sent to
him by the people in the translation team he reviews them and commits them to SVN.

Does this whole mess of an idea also contain a solution for “synching downstream”?
One of the reasons why the Release Team initially decided to adopt 6 months
releases is to make it easier
for downstream (distributions, for example) to ship a recent version of KDE.
The thing is that those distributions also have different heartbeats, OpenSuse comes
8-9 monthly, Fedora comes 6 monthly, others as well. Now we’re trying to
sync with upstream, in
different heartbeats and downstream in different heartbeats. Right now, we have
the unfortunate situation that we’re just too late for OpenSuse 11 (which is really
one of the symptoms of “heartbeats out of sync”). At last year’s Akademy, Mark
Shuttleworth brought up the idea of synching release over the whole Free software
stack. While this is a nice vision, I do not see this happen ‘globally enough’ so
that it really works. The trend
in the Free Software
world seems to be to move to a more distributed way
of development.

This “we all breathe synchronously” might be one of the things that ties us
together. We’ve seen this a lot in the time up to 4.0. That was where we as
a community acted as one and lifted KDE from ‘utterly broken’ into a
releasable desktop. In KDE 4.x, things are fundamentally different. With all
the new frameworks and libraries solidly in place now we we want this to be a
stable platform for a long time. That means we develop features on top of it
and fix bugs in the infrastructure and extend it – not break it. Basically that’s
the “Binary Compatible until KDE 5.0” promise.

Moving from one, proven style of development to another is something we
should not take lightly. On the one hand it would help us solving some
scalability challenges in the community (such as too many different people,
expectations, needs for their product and whatnot) and adopting new styles
of collaboration in a community where you’re free to share.

Things such as new ways of working together and the ever more diverse community’s
needs, expectations and lifestyles are not something we can ignore. We need to
constantly look at ourselves and our environement and think about how we can
improve it. Probably not one big step (“starting tomorrow we never freeze
trunk again, promised”) but hundreds of little baby steps.

Hideous GTK themes in KDE4 sessions.

For some time, GTK apps running inside my KDE4 session would not pick up their theme
properly, making them look hideous in their default theme. I’m using a small wrapper
script (/usr/local/bin/startkde4) to get my KDE4 desktop up and running. Since I’ve put
the “unset GTK2*” line into the script, GTK apps pick their theme again:


export LD_LIBRARY_PATH=/home/kdedev/kde/lib
export KDEDIR=/home/kdedev/kde
export PATH=$KDEDIR/bin/:$PATH
export KDEHOME=~/.kde4


. /home/kdedev/kde/bin/startkde

If you’re still living under the “I use a GTK1 app” stone, put another line for GTK(1) apps
in there.

Hope this tip keeps someone from tearing out hair. :)