All ur ChangeLog r belong to us.

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.

A pink KDE 4 desktop.
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. :-)