Changelog

Carsten suggests that the changelog should be in XML. So, in the spirit of avoiding the work I have to do to pass my degree, I hacked up a little XML changelog, with some XSL to turn it into HTML. The tarball is here. Untar it, and then run either

xsltproc changelog.xsl changelog.xml > changelog.html

for changes by app, or

xsltproc changelog-by-type.xsl changelog.xml > changelog.html

for changes by type.

It's just a proof-of-concept, so there are no doubt plenty of ways to improve it, but it's quite an elegant solution, and in purely technical terms, is probably the Right Way(TM) to do it (ie, XML changelog with XSL to convert it to HTML). However, the amaroK guys (I'm told) have a ruby script that produces HTML from a simpler, ad hoc changelog file format. Though lacking the technical elegance of the XML solution (he says, without having seen said ruby script), it might turn out to be the better option, since a simpler file format might mean more people adding to the file, and therefore a better changelog. Plus, I don't know ruby, so no one can ask me to maintain it :-).

Oh, and since I mentioned XSL, does anyone know of some kind of "templating" system for it, so I could write (say)

if condition {
   ...
   }

instead of the fairly unpleasant

<xsl:if test="condition"> 
   ...
   </xsl:if>

or the far, far worse way of sending parameters (arguments) to templates (functions). The basic ideas of XSL (templates, applying them with apply-templates) are really nice, but why oh why did they have to make it an XML variant? It's just nasty to look at, and seems like a particularly egregious case of "when all you have is a hammer...". OK, rant is over; we now return to your scheduled programming (and lots of comments telling me that I misused "egregious").

We're all coders now!

Or at least, I am (kinda). It's great to get a code patch into KDE (even if it is only about three lines long), having committed lots of docs over the years. And I can't resist saying that it proves that there's lots of low-hanging fruit in the bugs database, which can be fixed, or--in the case of wishlists--implemented with very little effort and knowledge. They're great ways to get involved in KDE!

WhatsThis?

If you read kde-core-devel or kde-devel, you'll have already heard about the proposal which the HCI team has produced for KDE 4. With input from usability, accessibility and documentation folks, they've produced a detailed design document for an improved way of linking tooltips, whatsthis and documentation. The document is quite long, so here's a mini summary of some of the main points:

At the moment, tooltips, whatsthis help and documentation are generally produced and presented to the user quite separately. In the HCI team proposal, they're brought together in a sort of natural progression of increasing detail: single-word or -phrase tooltips -> single paragraph whatsthis -> detailed docs. So, tooltips will present a way of progressing to whatsthis, which will present a way of progressing to the full documentation. This is one element of the proposal...

...The second element is to improve the usability of the whatsthis windows themselves. At the moment, the whatsthis help appears in "bubbles" which disappear as soon as you click anywhere. That's obviously not ideal, so in the HCI team design, they're "upgraded" to full windows, so you can keep them open while following the instructions in them, have multiple whatsthis windows open, move the windows around, and so on.

So far, it's just a design - what we need next is an implementation, so it can be tested, refined, and most importantly, so we can start putting content into the tooltips and whatsthis once KDE 4 applications are ready for it. So, if you're comfortable coding with C++/Qt/KDE, and you're looking for a way to get involved with KDE 4, please do contact me, and I can put you in touch with the HCI team, who will work closely with you to help get an implementation off the ground.