vizZzion.org :: sebas' blog.

GTK themes are fine again.

Sat, 10 May 2008 22:28:19 +0200

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?

Sat, 10 May 2008 01:05:19 +0200

Tom and Aaron 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.

Thu, 08 May 2008 12:58:09 +0200

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:

#!/bin/sh

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

unset GTK2_RC_FILES

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

Non-linear animations in KWin.

Mon, 21 Apr 2008 15:03:42 +0200

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.

Mon, 14 Apr 2008 22:08:34 +0200

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.

Sun, 13 Apr 2008 03:37:14 +0200

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

Thu, 10 Apr 2008 18:33:09 +0200

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

A KDE Office.

Fri, 04 Apr 2008 13:37:48 +0100

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

All ur ChangeLog r belong to us.

Mon, 24 Mar 2008 23:02:11 +0100

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.

A pink desktop.

Wed, 19 Mar 2008 19:52:10 +0100

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