Non-linear animations in KWin.

Some time ago I’ve done a proof-of-concept how one can make KWin’s compositing effects
use non-linear timelines. Before that, a KWin animation would feel a bit static. Think
of minimising a window. It would abruptly start moving at a constant speed and stop at
some point in the same, abrupt way. Now we have a wonderful class in Qt, called QTimeLine
that provides some additional curveshapes, making it easier to show accelerated or slowing
down movements. After some discussions on the KWin mailinglist, I’ve implemented a smallish
wrapper class around QTimeLine that is tailored towards the needs of KWin’s effects.
After review by Mr KWin, Lubos, I’ve committed it to KDE’s SVN last Friday, and along with
it ‘port’ of the minization, the desktop grid and the coverswitch effect. Making those
effects use the new KWin::TimeLine class wasn’t hard at all (well, modulo on where I
needed some help ;-)). In fact, the coverswitch effect was done in 5 minutes during the
last beer of the Tokamak Plasma sprint. Now at least those three effects feel more natural,
less static. More effects will be ported later on, if you want to get your hands dirty, feel
free to have a look at it.

During the last week, we’ve done some more polishing to KWin effects. Aaron has made the
coverswitch effect more beautiful, and made the mousemark one (the one that shows stars
revolving around your mousepointer) a bit less jumpy — it now ‘feels’ like it’s always
revolving, but not always shown — and not ‘start at position 0 whenever shown’. Last night
I’ve excluded some window types from the brand-spanking-new Wobbly Windows effect in KWin.
Previously, menu would wobble as they pop up, making for a hectic user experience when
opening various menus in short order. It seems that not all Windows know what they are,
but at least having it working for menus is quite an improvement already.
I’ve also
made windows become translucent as they are being minimised, making it look a bit fancier.

Hacking on KWin is actually a lot of fun. You can do a lot with very little, the code in
most of the effects is (at least partly) easy to understand and modify, and the results
are very visible, which I think is a good motivator.

We broke Plasma.

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.

fkefer is out of laptop.

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. :-)

Lies, damn lies, … .

… 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.

trunk since 4.0 has been tagged.

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

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

number of commits to KDE and GNOME SVN repositories.

number of distinct authors in KDE and GNOME SVN repositories.

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

number of commits between KDE 4.0.0 and 4.0.1.

number of commits between KDE 4.0.1 and 4.0.2.

number of commits between KDE 4.0.2 and 4.0.3.

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.

A KDE Office.

Claudia Rauch, KDE e.V.'s first employee.
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
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. :-)