Category: KDE

After Alexis has torn Plasma into pieces yesterday, some brave individuals svn up’ed, rebuild
kdebase and started putting the pieces backtogether. There are huge amounts of fallout right
now, but we’re getting closer to having some basic applets back. Currently digiclock, battery,
kickoff kind of work (modulo some layout problems in the panel), taskbar at least compiles
after some frenzy porting over the last hour. All this feels like a fast-track through the last
year-and-a-half through Plasma development. I can remember very well when we first saw a panel
and rudimentary clock appearing, the same happened today with much “ooooh” and “aaah” … :-)

But Why? you might ask yourself, it started to look polished and now it’s
broken again. Well, Plasma in KDE 4.0 was based on Qt 4.3. Qt 4.3 lacked the widgets-on-canvas
support Qt 4.4 has. That means that layout managers and widgets had to be written from scratch
for 4.0. Now KDE’s trunk/ requires Qt 4.4, including the widgets-on-canvas (WoC) support, we’re
able to use QWidgets, and maybe more important Qt’s layoutmanagers in Plasma applets and
containments such as the panel. So we were able to remove large parts of code in favour of
using Qt’s functionality — less maintainence burden, less bugs, less memory consumption and
all that included.

And while that fixing of the WoC fallout happens, the next round of breakage is on the horizon:
Kevin, Richard and Aaron and The WhiteBoard have gone through all the classes in libplasma in order
to polish that, remove braindeadness and a couple WTF’s
in the code. The plasma API should become much more intuitive, easy to use and future-proof. The
downside being another round of breakage and fixing all over the codebase. We expect the results
of the API review to hit trunk/ later this week — including the breakage it introduces. After
that, we hope that libplasma is stable enough to have it move over to kdelibs, currently that’s
planned for the 4.2 timeframe. I’ve put the
results of the API review online. As to the “Which face does this SVN account belong to?”,
that’ll come later. Besides a working desktop, one needs something to look forward to. :P

So if you’ve compiled trunk/ after yesterday and wondered what happened and why someone visually
bombed it back into the stone-age (last year ;-)), now you know why :-)
If you want to help fixing up things, update trunk/, join #plasma on freenode like others do
and fix obvious breakage. It’s not necessarily hard, but there’s quite some code crunching involved.
Do tell others on IRC what you’re fixing so duplicate work is prevented. Looking at the current
flurry of patches gives you a good idea what to replace with what.

Of course this is all done during Tokamak, the Plasma sprint in Milano where we’re hacking
on your favourite desktopshell since last Friday. More exciting stuff has happened, but more
about that later, and of course in other Plasma hackers’ blogs. Suffice it to say, we’re
mightly productive and very cool things are on the road ahead.

So after we worked
on priorities thanks to our awesome Celeste, Franz Keferböck showed us his
version of priorities. He visited us down here in Milano at the Tokamak Plasma Sprint,
bringing Stevie, his girlfriend, a case of fine Austrian beer, but unfortunately he forgot
his laptop at home. Now that’s what I call priorities. :-)

… and statistics. Last week, I took a python script that I had written some time ago for
CodeYard, modified it a bit and
analysed some recent KDE subversion logs. I’ve taken a look at the number of commits in
the KDE 4.0 branch, and a bit in trunk/. I’ve also compared number of authors and commits
to the KDE and GNOME Subversion repositories since 2004. I’m discussing my findings below.
Of course, being Free Software, research and all, I’ve put up the script and data so you
can run with it and create your own reality.

This graph shows number of commits and authors in trunk since KDE 4.0.0 has been tagged. We see the this
number is quite a bit higher than even the sum of bugfix and translation commits that has gone into the
4.0 branch. That, I think does reflect well that main development is taking place in trunk (no surprise
there), and that trunk is probably quite a bit ahead (in terms of instability? :)) compared to
4.0-branch.

I do not quite understand the high number of commits in the 4.0-branch. I’ve fed the log starting with
rev 757456 until HEAD to the script. I would’ve expected the number to be roughly the sum of 4.0.1,
4.0.2 and 4.0.3 logs. I wouldn’t be surprised if there a bug in my datacollection
script. Email me if
you know what’s going on there.

KDE and GNOME Compared

This graph gives a long-term impression of the number of commits and distinct authors per month in
both, KDE and GNOME subversion repositories. Some observations:

• KDE and GNOME are pretty similar in size
• Only recently (roughly since the beginning of 2007, there’s a real
  difference in the number of commits
• Since the beginning 2007, the number of KDE commits has grown by ~20%
• Lately, there seems to be more difference in the monthly numbers for GNOME
• Because the numbers have been so close to each other, it’s looks like we’re not competing,
  but that what’s good for one is good for the other. So having GNOME doing well suggests that the
  climate for KDE is also friendlier. This has been less evident lately, however.
• The number of rises close to their six-monthly releases
• As of lately, the number of KDE commits is higher than the number of GNOME commits, GNOME has
  slightly more distinct authors monthly

• There is certainly no exponential growth in the number of Free Desktop developers. If we
  believe these number which obviously(*1) do not include third party authors (*1) not
  as long as I define “third party authors” as “those not developing their software in KDE’s and
  GNOME’s SVN repos” anyway :-)

Of course you’re free to interpret those numbers in your own way, the above is just what I can
come up with when looking at those numbers. I’ve also put up the OpenDocument file with the raw
data in it, so you can play around with it in a similar fashion. Find it
here and show us your
interpretation of reality ;-)

KDE 4.0 Branch

Here we see the number of commits to the KDE 4.0 branch in Subversion. Two things are striking:

• The 4.0 branch is calming down. Reasons are probably that the
  more obvious bugs are fixed, and that more developers have switched
  to using trunk/ that is going to become 4.1 this summer. I would have
  expected such a trend.
• KHTML and KWin people are doing really well (and “Plasma-Ruphy” in 4.0.2), this is also reflected
  in recent changelogs. It doesn’t say a lot about development progress,
  since the 4.0 branch is focusing bugfixes and performance improvements.

KDE e.V. the foundation backing KDE legally,
financially and in many different ways has
traditionally been a very ‘lean’ organisation. In its first ten years, the KDE e.V. has
been run by volunteers from the KDE community. This has lead to interesting situations in
the past. Developers doing accounting is my favorite stupid thing (not because they’re bad
at it, they’ve done an awesome job) because we badly need those developers to work on KDE —
and it’s probably not their favourite thing to do (not *my* favourite thing to do anyway).
So during the last years, we’ve worked towards stabilising KDE e.V.’s financial situation
so it allows for a commitment, the commitment you need when someone becomes financially
dependant on you. We’ve managed — also thanks to our Patrons and Supporting Members —
to be confident about our situation, both organisationally and financially.

We had been in contact with Wikimedia
Deutschland e.V. for some time already. It had been
brought up earlier that our organisations are pretty similar in what we do (supporting
a volunteer project in the Free Culture domain). It was also proposed to to share
resources, such as an office. But we’ve been struggling for some time moving forward in
this process. Those among the readers that went through their own start-up phase can
probably tell you that getting the first employee is a pretty big step. We’ve
mastered
that now, and that’s something we’re very happy with.

The building in Frankfurt where Wikimedia Deutschland e.V. is located had some spare rooms,
most notably one adjacent to the Wikimedia office when a policy window opened. Wikimedia
wanted to hire an administrative assistant, and that’s also something we were looking for.
In December,
we’ve moved forward. Klaas and I travelled to Frankfurt (which is incidentally pretty much
in the middle between Nürnberg and Nijmegen) to meet Claudia Rauch, a proposed
candidate for the position of KDE Office Dudette. The vibes were good, her background
consolidated that first feeling so we decided to go ahead. The situation now is the
following: The official address of KDE e.V. has moved from Eva’s private address to Frankfurt,
Rödelheimer Bahnweg where our office is located. The office is run by Claudia who is
hired part-time to support the KDE e.V. in mainly administrative things. The scope of her
work can of course not be completely sure at this point. KDE e.V. is a quickly evolving
organisation, and you never know tomorrow’s challenges. Short- to mid-term, having an office
and someone to run it will alleviate us of some of the more urgent administrative tasks.
The “performance” of the KDE e.V. will improve through that. Now you ask yourself what this
performance is, and rightfully so. It expresses in turnaround time for travel cost
reimbursements and other administrative requests the KDE e.V. Board gets. It also means
that we can offer some support to organisers of Akademy and other conferences and sprints.
The office in Frankfurt will also be the new home of the KDE Boothbox, a rugged aluminium
case with equipment one typically needs at events, such as demo systems, signage, cables,
and so on. The boothbox has already found its way to Frankfurt. You can request to have it
shipped to the event your planning to represent KDE at. This process has not always been
as smooth as we would have wanted it to, but we hope for quick improvment now.

Next Thursday, I’ll be travelling to Milano to take part in the first Plasma sprint ever,
meeting some of the people I tend to be hacking with on the same projects. After that sprint
Aaron, Peyton and me will be going to Frankfurt for a two-day Board meeting. That will be
the first Board meeting hosted by ourselves. :-)

We (marketing / promo hat on) are right now trying to write the announcement for KDE 4.0.3,
which will be released on April 2nd, a bit more than a week from now. Let’s have a look at how
this actually works, and zoom in on the bugfix / translation updates that 4.0.x releases are.
The announcement is usually written by a subset of the Marketing Team, coordination takes place
on the kde-promo mailinglist. On this list, people that are willing and able to write about KDE
hang out. Those people are collecting information about those releases. For a big thing such as
KDE 4.0, this is relatively easy, there’s more than enough to talk about. For an update release
(such as next week’s) we’re mostly relying on the changelog as raw material. We try to form an
impression of what’s happened in branch in that period, and munge that into something which is
readable for human beings and provides a high-level summary for those that won’t dive into
details. Then, the original announcement version is written and ASAP (though usually too late)
sent to the translation teams so we have a multi-language announcement ready on release day.
The trade-off here is: Writing the announcement earlier, the changelog will be incomplete, but
the translation teams get more time, so we end up having more and better translations on
release day. Writing the announcement later, there’s more in the changelog (although
unfortunately not much more :/) but the translation teams have too little time, so we lack
translations. Having a more complete changelog available earlier is the solution to this
problem. So we need help from developers. Kudos at this point go out to the KHTML and Okular
teams, who, from the top of my head, usually have done their changelog homework well.

For the lazy ones among us (most, assumably), here’s what you do (assuming you use svn+ssh,
https users will what to change):

svn co svn+ssh://svn.kde.org/home/kde/trunk/www/sites/www/announcements/changelogs
kwrite changelogs/changelog_branch_4_0.xml

Scroll down to a line that looks like <release version=”4.0.3″ date=”2008-0?-??”>, scroll
down a bit more, to the part containing the module and product your changes went in, and add them.
You can use the tags bugfix , improvement <improvement rev=””>, feature <feature rev=””> or whatever is
documented in the DOCS. In practise,
it’ll be a bit of copy/pasting. Commit your changes and have a smile on your face when you read
about your improvements in the announcement a few days later.
If you want to see what you’ve done, run the following on the changelog and see your
changes put into the webpages:

xsltproc --stringparam outputversion "4.0.3" -o changelog4_0_2to4_0_3.php
changelog.xsl changelog_branch_4_0.xml

I think this ignoring of the changelog is a display of a culture that we see quite often
within KDE. A culture that is very humble and fully concentrates on getting work done. Only in
this case, it causes problems for others that also want to get their work (informing about KDE)
done. So if you changed something in the KDE 4.0 branch between 27th of February and 26th March
(this coming Wednesday) please support the Marketing Team’s work by adding your change to the
changelog. Remember, if a change is worth backporting, it’s worth putting in the changelog. The
more entries there are in the changelog, the more choice the Marketing Team has to streamline the
message. Of course, also the ‘raw’ changelog will be available to the users, usually linked from
the announcement on www.kde.org and multiple other sites reporting about KDE 4.0.3. Users will
look for their pet issue being addressed. The Marketing Team does an awesome job in communicating
what’s happening (who doesn’t love reading the Commit-Digest for example?), but they can’t do
that on their own. Please spend those 5 minutes and help your fellow gearhead.

During the release event in Mountain View, there was also a distro BoF where upstream
told some KDE people about things they’d like to see in KDE. One of those things is that
the desktop should be easy to brand. It should be easy to create a product out of KDE (which
is really a raw product). Themability makes it easier to brand KDE in a way that reflects
the Corporate or Community Identity of distributors.
In the screenshot you can see how far we’ve come along that way. Since the Fluffy Bunny
theme has developed into some kind of running gag, I decided to make my desktop something
that would make Mira
say “I want KDE!”. The result can be seen in the above screenshot. I’ve been using this setup
for some days now, and I must say that, even while I’m not a huge fan of pink, it looks very
slick and calm. It’s definitely something I can work with.

So what can be seen in the screenshot? There’s the Aya plasma theme which changes its look
based on the system colors. We can hint SVG files used in the Plasma widgets and tell them
something about the colorscheme in use. You see, the panel is also nicely pink, it just picks
up the colorscheme that’s setup in System Settings. Also, the first Plasma themes start to
turn up so you already have some choice in creating the looks you want. Jeremy has just
very
recently added Get Hot New Stuff support to the “Configure Desktop”
dialogue, so installing new themes is now very easy. The grumpy guy can see on the bottom left
of the screenshot is Chuck Norris. While I’m also not particularly into Chuck Norris, it’s
actually very cool that Mr Norris made his way onto my desktop. It’s not a Plasma applet, it’s
an OSX Dashboard widget. Yes, we can already load dashboard widgets onto our desktop, thanks to
Zack and Aaron spending a couple of days (nights?) together hacking.
Then, not exactly Plasma, but still very cool is the hovering selection that’s new in Dolphin
(or more technical in KFileItemDelegate). On the screenshot you see that a few directories
are selected. That would need to be done either by dragging a rubberband around them selecting,
or by holding CTRL pressed and then clicking. “Desktop” is hovered when the screenshot has been
taken. You see a small green + in the top left corner, click on that + and the directory is not
opened, but selected. Click anywhere else on it, and it’s opened. That makes it really easy to
make and edit a selection.
A couple of days ago, a folder plasmoid has been started in KDE’s playground in SVN. Fredrik
Höglund is working on that. This plasmoid will probably make it possible to have multiple
folders on the desktop. Plasma people don’t like the idea of having the desktop only represent
one directory on your system when you can have multiple of them.

And all that (and much, much more) has happened in just 2.5 months. In April, there will be a
Plasma sprint in Milano
where more coolness will be planned and implemented. Plasma is quickly catching up with the
functionality people have been used to in KDE 3.5 and has surely exceeded that in some areas
already. Even for those strange individuals that don’t like pink, or Chuck Norris, or
combinations of those two, this just has to be impressive. :-)

Yesterday, Sebastian Sauer commited some changes to the Plasma panel that make it possible
to resize it. This has been a much-wanted feature. Earlier already, Olivier Goffart has made
it possible to have two rows of tasks in the taskbar, and also to only show windows from
the current virtual desktop in the taskbar. Result is a much better configurable panel now.
You guys rock. :-)

I sat down and started fixing some applets
that didn’t behave quite well at small sizes. One victim was the digital clock. The battery
now tries a bit harder to squeeze itself in the space it gets, and the panel now actually
respects the taskbar font setting from kcontrol. I’ve also added some animations to the battery,
so now if you unplug your AC adapter, you can actually see the AC adapter flash
disappear, so the battery applet gives the user a bit more feedback. Also, the label
showing the charge percentage on top of the battery now fades in and out nicely.
Plasma::Phase goodness all over. :-)

On other news, during the last days, I also gave an
email
interview to Richard Hughes for Linux Tech Daily.

Sunnyvale, CA. Earlier today, two Plasma hackers have been assaulted by
a crocodile while taking a short break from their quest for world domination. The crocodile has later
been hunted down by a KRunner
and lost its life in a Plasma crash. Original photos from the crime scene show one of the Plasma hackers,
Riccardo Iaconelli proudly
presenting
his prey.

The incident happened the day after the developers had celebrated the release of KDE 4.0, an innovative
piece of software, written by a bunch of hippies and commies.

Sources on the ground in Sunnyvale reported that the victims are doing fine. They are
both
recovering
from the shock as we speak. Iaconelli, one of the victims states in an exclusive interview with yours truly:
“You know, we’re doing a
dangerous job out here. KDE development is not always as peachy as we’d like it to be, but someone
has to do the dirty work.”

Earlier today, the KDE Release Team came up with a rough release schedule. This schedule is actually
two-fold. Bugfix releases will come out every month, at least for the next half year. The next real
feature release will be KDE 4.1 in July 2008. Furthermore, KDE will be releasing a new feature version
every 6 months, so KDE 4.2 will be there in January 2009, 4.3 in July 2009, and so on. We hope that
this way, we make it easier for both KDE people and distributors / OSVs to plan.

Plasma might see an intermittent release in the meantime,
which is made quite easy with our improved infrastructure,
so early adopting users won’t need to wait until
July for some sorely missing features (resizing, moving panel, anyone?!).

So what’s in the pipeline for KDE 4.1? Let’s see:

• Mac Port
• Windows Port
• OpenSolaris Port
• Plasma with widgets on canvas, makes things like layouting much easier, and generally
  integrating widgets into plasmoids
• Webkit in plasma
• Apple dashboard widgets support in Plasma
• Decibel VOIP and real-time communication framework
• Dragon Player multimedia player
• More polished kopete
• KDevelop and KDevplatform
• KDE-PIM, based on Akonadi
• GetHotNewStuff2 / DXS
• Plasmagik plasma packages and add-on creator
• Lots of smaller features

Impressive huh? Actually, a lot of those things is close to being done already, and of course, we’ll
be seeing the ‘usual’, but nonetheless important things like performance improvements, UI polish,
artwork updates, translation and localisation improvements, bugfixes, newly ported applications, new
‘smaller’ features in applications, new plasmoids, more data on GetHotNewStuff, new KWin compositing
effects, and so on …

As KDE 4.1 will be based on Qt 4.4, we’ll get some things for free: new backends for Phonon (gstreamer,
DirectShow, QuickTime), performance improvements in SVG rendering, alien widgets for smoother resizing,
webkit (there’s a KPart being written by Trolltech peeps, and more freedom with
GPLv3. (And
the stuff I forgot :-)).

Around the same time, KOffice 2 should be available, which is another really big thing. Amarok2 also
looks quite promising already, but I don’t have exact data right now (could walk over and wake up
Jeff Mitchell, but not sure if he’d like that ;-))

Disclaimer: Please note that this is not an official list, nobody guarantees
that all or any of the above will end
up in KDE 4.1. Right now, it looks like all this stuff will make it into 4.1, lots of it is even close
to being finished already. In any event, don’t complain if not everythings makes it into 4.1. Also, this
list is not exclusive, so there will surely be more new things.

Just returned from a break-out session with some kernel developers who are here at Google where we
discussed a couple of things that can be improved in the current Linux kernel for a better
user experience. We, that is a group of KDE people from different areas, among which aseigo, Dirk,
Thiago, Will, Zack — in randomly alphabetical order. Kernel people in this session include Natalie
Protasevich, Andrew Morton, Daniel Phillips and Gary Greene.

Issues that have been discussed are limitations in inotify where we’d like to be able to watch more
files at once for changes, the most notable use case being desktop search and indexing. Another
interesting issue we’re facing is bad guessing when trying to keep interesting things (such as a
maildir with lots and lots of small files in cache) when dealing with large I/O. This is actually
something we can improve ourselves by using fadvise to tell the kernel what makes sense — the kernel
cannot reasonably be expected to know the purpose and usage of data, so we need to tell it somehow.

Of course, my pet-peeve and the ever-interesting issue of suspend is another big issue with the Linux
kernel we currently have. While it is on the radar of the kernel devs, we made sure that they
know how important that is to us. In my opinion, the solution to this is two-fold. As it’s mostly
drivers that are responsible for the rather bad user experience currently, drivers need to be improved.
Open drivers can obviously be fixed much easier for the kernel developers, but it also helps if
large companies can kick each other when they’re screwing up suspend and hibernate.

Most important outcome of this meeting has probably been the opening of communication channels.
Andrew told us that the best way to get our issues addressed is filing bugs (as emails), voting
for them to justify resources put into them. Andrew also told us that sending such a bugreport
from a @kde.org email address will prioritise it, which is I think important to know for us. Kernel
people really want to help us, getting them the information they need will make it easier to fix
problems we face when using the Linux kernel. Such a bugreport ideally includes a testcase (code!)
which shows the problem.

Needless to say that I’m very happy we got the chance to exchange. Thanks everybody involved! Also,
I should probably pass on Daniel’s “Thank you for creating KDE!” to you all.