Things Phil Finds Interesting

POST

2007-02-12T19:44:00.000Z

In the true spirit of the lazy web, I'll put this out and see if anyone wants to take it up:

I'd like to improve kbugbuster to help with KDE bug triage. One of the main limitations at the moment is that it can only use the email interface to make changes, so that limits the app to closing bugs as FIXED, and very little else. So, what I want is a way to make any type of changes allowed by bugzilla. The only way I could find was to "fake" being a web browser by sending HTTP POSTs. But try as I might, I can't get it to work. Making comments or changes to bugs in the KDE bugzilla just POSTs the form data to the process_bug.cgi script, but whatever I try, I get strange errors from the server.

So, does anyone out there think they can do a better job of this? Ideally, I'd like to have C++ code using the KDE libraries to do this, but any kind of code would be fine - I can probably convert it to C++ if I can see exactly what's needed.

Guest blog!

2007-02-05T09:23:00.000Z

So I'm playing at being a real blog writer, and having a guest blogger for this post. I guess Kurt Pfeifle needs no introduction, but here's some relevant info:

Kurt is a long-time KDE contributor, and living proof that you don't have to be a coder to have a real effect in improving KDE. He does a lot of work on the KDE Print system (just take a look at all the whatsthis help in the printing dialog), and has recently done a lot of work triaging kdeprint bug reports. He's currently working on the notorious problems with producing PDFs from KDE applications.

I need a bit of help from some Qt or KDE developer guru.

Here is the problem: an unknown-to-me (and escaping-my-tracing-attempts) process keeps writing into my qtrc setting file(s) one specific key value that I want to remain unchanged. I want it to remain "embedFonts=false" as long as *I* tell it so; but some alien thing reverts it to "embedFonts=true" after each and every time I printed something.

Here some more details about my qtrc problem.

I know of 2 GUI applications that write this specific setting, when a certain checkbox is enabled:

"kaddprinterwizard --kdeconfig"; select "Fonts"; enable "Embed fonts in PostScript data when printing"

"qtconfig"; select the "Printer" tab; activate "Enable Font Embedding"

The button "System Options" in kprinter does also start this same dialog ("kaddprinterwizard --kdeconfig".)

Here is what I do:

open a KWord document

start the print dialog

click button "System Options" (i.o.w.: "kaddprinterwizard --kdeconfig")

make sure fonts are *not* embedded; confirm

select the "Print to file (PDF)" printer

print it

Here is what happens:

Next time I want to print...

...I start the print dialog...

...I click button "System Options" (i.o.w.: "kaddprinterwizard --kdeconfig")...

...and annoyingly, I find that in the meantime, font embedding has magically been re-enabled!

The file qtrc comes in different incarnations:

/etc/X11/qtrc (for system-level settings). This one is used, when root runs "qtconfig".

$HOME/.qt/qtrc (for user-level settings). This one is used, when user runs "qtconfig" or "kaddprinterwizard --kdeconfig".

I assume, the settings in $HOME/.qt/qtrc should override settings of the /etc/X11/qtrc file for a user.

I verified that my clicking/confirming the change in the KDEPrint GUI does indeed write into the qtrc file momentarily. But as I said, this gets again reverted by another process. I also manually edited the system-wide /etc/X11/qtrc file and made sure it had "embedFonts=false" when I saved it. The above described behavior still remained unchanged, and even that system wide /etc/X11/qtrc file got reset!

I don't know who or what does mess with my qtrc file(s) and who or what resets my configuration to something I do not want for now.

For now, as a temporary workaround, I have changed permissions to all qtrc files found on my system to "0444" (read-only for user, group and others). This now ensures that my darn "embedFonts=false" entry remains stable; but this hack obviously is not exactly what the doctor ordered, and may lead to other problems on other corners of the system which I currently am not aware of....

So here are my questions to you:

Does this happen on your system too? (Mine is a SUSE-10.0 with qt3-3.3.7-9.3 and KDE 3.5.5, *and* libqt4-4.2.2-2.1 *and* libqt4-qt3support-4.2.2-2.1... but in any case, Qt4 doesn't seem to use a qtrc file any more.)

How can I find out who/what is re-setting the qtrc file behind my back?

How do I get rid of that behavior???

Result!

2007-01-09T08:47:00.000Z

Just a quick post to say that the Konqueror bug triage weekend was a huge success. Some highlights:

Getting the number of unconfirmed konqueror bugs (excluding wishes) down from over 950 to below 800.

Making konqueror green (ie, more bugs closed than opened) for the last 6 months. Of course, this builds on the great amount of hard work done over the longer term by the konqueror developers and other triagers, but as Adriaan would tell us, it's a nice metric.

mafitzpatrick's incredible testcase work. I don't know how he does it...

Kurt Pfeifle getting through all the khtml printing bugs

Of course, they weren't the only people working hard over the weekend - illogic-al, bram85 and logixoul did some great work co-ordinating the whole thing, and many more people checked, confirmed and otherwise triaged a lot of bugs. Thanks to all of them!

And some thoughts I had that we can try out next time:

Triage newer bugs instead of/as well as older bugs, since they're quite a different kettle of fish - easier in some ways, so nicer for people who haven't done triage before.

Make lists of bugs in one particular component, to aid in finding duplicates

Someone suggested we do KOffice next. Perhaps putting it here will help us remember :-)

The main bug weekend is over now, but if you want to get involved and help out with bug triage, just drop by in #kde-bugs on irc.freenode.net sometime.

More bug triage!

2007-01-04T20:04:00.000Z

We've got another bug triage extravaganza planned for this weekend, the 6th-7th. So if you're free and you feel like helping KDE, drop by #kde-bugs on irc.freenode.net for a bit - it's really easy, and all you need is a recent KDE installation. Some tips on bug triage can be found here.

Looking forward to seeing you there!

Grand!

2006-09-08T09:24:00.000+01:00

They said it couldn't be done[1], but we've got the number of unconfirmed Konqueror bugs (excluding wishlists) below 1000, from 1305 a couple of weeks ago:
Unconfirmed konq bugs.
There are also a huge bunch waiting for feedback ("Works for me. Does the bug still occur for you in KDE 3.5?") of which many, I suspect, will be closed in about a month.

1. OK, so no one actually said this, but it does look a daunting task...

Bugs!

2006-08-28T23:05:00.000+01:00

Following a post on kde-devel about the number of UNCONFIRMED konqueror bugs, a few of us are going to try having a "konqueror bug triage day" this Wednesday, 30th Aug. We'll meet at 3pm UTC (10am CST, 5pm CET) in #konq-bugs on irc.freenode.net, and go on until whenever we like.

The aim is to sort through the bugs that have been reported, removing duplicates and bugs that are obsolete, so that the developers can spend their time fixing bugs instead of trawling through bugs.kde.org

We'd love to have more people to help, so whether or not you've done any bug triage before, please feel free to join us. All you'll need is a recent version of KDE (at least 3.5, but the newer the better), and a big of perseverance.

If you haven't done any bug triage before, you might like to
read these two pages to get an idea of what it involves:

Let's go away for a while

2006-05-04T19:09:00.000+01:00

Exams are looming, so it's time for my annual disappearance from all things KDE. If you need to get hold of me, I'll be checking my email (philip-rodrigues-at-chch-ox-ac-uk).

Changelog

2006-04-11T22:33:00.000+01:00

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!

2006-04-06T21:05:00.000+01:00

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?

2006-04-05T09:16:00.000+01:00

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.

2006-03-22T17:40:00.000Z

I've got a little bit of free time, so here's the first in what will
hopefully become a series of hints and tips about getting involved in
KDE without having to learn C++.

Today's topic is bug triage. Around 80 new bugs and wishlist items are
filed in KDE's bug tracking system
every day, and, while application and library maintainers try to look
at all of the ones reported for their application, their job is a lot
easier if someone else has already gone through and removed the
duplicates, asked the reporter for any additional information that's
useful, and noted which bugs can be reproduced.

The really nice thing about bug triage is that it comes in very small,
bite-sized chunks: each bug report probably takes a few minutes to
look through, so you can spend ten minutes a day on bug triage (on
your coffee break!), and be able to do something useful - something
that isn't so practical with some other ways of helping KDE.

The main reference for bug triaging, which I'd thoroughly recommend,
is the quality.kde.org
bugs howto. That'll give you some pointers for getting started,
and tell you a little about how the bug tracking system works, what
the different bug statuses mean, and so on.

So, once you've got an account on bugs.kde.org and read the
quality.kde.org howto, what do you do next? The first thing to do is
decide which bugs to concentrate on: do you want to look just the bugs
for one or two applications, or take an overview of al bugs that are
reported? If you're a long term KDE user, and are a little bit
familiar with the internals, then taking an overview might be for you:
you'll be able to see when bugs are filed against the wrong KDE
component, and suggest what other parts of KDE could be relevant to
the bug. If you're not familiar with the internals of KDE, you can
still do bug triage! Just pick an application you use a lot, or
particularly like, and concentrate on the bugs that are reported for
that application.

Let's say you decide to concentrate on bugs in one particular app. You
can use the query page to
display all the open bugs for that application, or just the bugs that
have been opened in the last few days. Take a look at each bug, with
the aim of determining whether or not the behaviour that the reporter
described is really a bug, and if so, making it easier for the
developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to
start fixing the bug?

Some things to do:

First, try to reproduce the behaviour that the reporter has
described. Add a comment to say whether you could reproduce the bug,
noting your KDE version and distribution. If you don't understand the
description, ask for clarification - if you can't understand what the
reporter means, the developer probably won't be able to either.

If you can reproduce the behaviour, think of ways to narrow down
the cause: Imagine that an app crashes when you save a document. What
about selecting Save from the File menu? What about pressing Ctrl+S?
Does it happen for any document, or just certain documents (perhaps
certain file formats)? What about local vs remote files? This is where
you get to use your imagination a little bit, since every bug report is
different.

Try to find out whether the bug is related to a problem with
config files: trying to reproduce the bug with a newly created user
(and asking the reporter to do the same) is a good way to test
this.

Those are some common, simple things that I can think of. As you get
more experienced, you'll find other tips n' tricks that are useful,
especially if you choose to concentrate on just one application.

So, in 20-second summary:

Bug triage

Why's it useful? It makes bug hunting and fixing easier for
developers, so more bugs get fixed.

Why choose bug triage instead of ...? It doesn't take much time
to look over a bug, so it comes in nice small chunks

What skills do I need to do it? Not much, just a bit of
patience and sometimes some perseverance.

Serendipity

2006-03-11T22:45:00.000Z

So I said I'd write some mini-howtos on non-coding ways to get involved with KDE. Kevin Krammer has beaten me to it, and he has some good information and insights.

I don't have time to write a full mini howto, but I have a neat story about bug triage, and how the contributions of non-coders and coders can all come together quite nicely.

It began (for me at least) with flicking through the bug reports, looking for anything I could usefully comment on. I noticed that bug 122218 and bug 122158 looked quite similar, so I added a comment to each bug to say so. Lubos fixed the second bug, and added a comment to the first to note how he'd done it. Enter Ismail Onur Filiz, who, on finding Lubos' explanation of the fix, codes up a patch. It's reviewed and applied, and there's one less bug in KMail :-).

I'm quite pleased with that story, since it shows how non-coding contributions can help things happen, even if they're not directly producing the end result, and it makes me feel that my occasional bug triage attempts are useful.

2006-02-24T20:01:00.000Z

If I'd had a pound for every time some KDE user has said something
along the lines of "If I could code, I'd contribute to KDE," I
wouldn't be writing this on a laptop that was bottom-of-the-line when
I bought it three years ago.

So, if you're a KDE user who has at some time or another thought or
said exactly that, what can you do? Well, there are two options:

Learn to code! I get the impression that some people think that the
KDE coders entered the world with innate knowledge of C++ and Qt,
and wrote their first KDE application just before saying their
first word. They had to learn it just like the rest of us. It's not impossible to learn C++/Qt/KDE. Granted, it's not as easy as some other programming languages, but many
contributors have proved that it can be done: just ask annma.

Get involved with one of the very valuable non-coding tasks that
help make KDE better. They range from writing docs and doing
translations, through artwork and usability studies, to maintaining
websites or doing bug triage. While these might not have the same
"wow" factor as coding that killer feature, or fixing that
long-standing bug, they're still extremely important to KDE, and
can be just as satisfying.

For example, take bug triage: KMail alone receives about 30
comments to bugs every day. The majority of these are users
either reporting new bugs/wishes or adding a comment to existing
ones. The small team of developers working on KMail can keep up
with these bugs a lot more easily if someone has already looked
through them and removed duplicates, confirmed those bugs which are
reproducible, and added any other useful information.

It won't make you the next Linus, but it's one way to get to know more
about KDE, and in the end it helps make KDE better.

I think I'll write a few blog entries over the next few weeks going
into more detail about specific ways to get involved. Maybe I'll even
polish them up enough to become dot articles. Which reminds me, I have
some notes of Aaron's "10 ways to get involved in open source" talk
which I should turn into full sentences so they can be article-ized.

"Kafkaesque, isn't it?"

2006-01-31T23:39:00.000Z

An amusing bit of randomness that makes life more interesting: it turns out that some teenager in Québec goes by the MSN user name of accengrave at hotmail.com, whereas I'm accentgrave at hotmail.com. So of course, he tells his friends his username, and they add me instead (serves 'em right for not pronouncing all those letters, I suppose ;-). I think I now have most of this guy's friends in my contact list, and I've spent plenty of time trying to decode "MSN French" (evidently the Académie Française hasn't managed to extend its influence as far as IM-using teenagers).

In KDE land, not a lot's happened. I want to have some time to work on ways to turn the hype about KDE 4 into well-directed effort. People turn up in #kde asking when KDE 4 will be out, trying to build trunk, etc, and it would be great to be able to tell them of good places to direct their energy (seeing as building trunk isn't exciting at the moment unless you're hacking kdelibs, AIUI). Aaron's talk on "10 ways to get involved in KDE" has some nice ideas. Perhaps a dot article on "10 ways to help make KDE 4 the best ever" would be useful. Alas, time doesn't permit at the moment, with university life taking it all up.

I did have some fun(?) chasing down a bug in the audiocd:/ slave on FreeBSD a few weeks ago, which is a lot of fun if you don't know C++ and are just randomly adding kdDebug()s and messing around with gdb. With some help from people with clue, I tracked down the problem in the end - [ade] probably blogged about it already, so I'll skip the details.

And I have a memory dump lying around from a FreeBSD kernel crash too. Perhaps looking at that would be setting my sights a little too high...

Mini-tip

2005-12-13T16:06:00.000Z

For want of anything more interesting to write about, here's a little tip I came up with in response to a user's question on #kde.

The situation was this: The user has a konsole open with four tabs, each one showing the output of some "tail -f" command (with a different file for each tab). The question: how to have this setting saved and restored at login?

Well, my solution is a bit of a hack, and probably isn't the simplest way to do it, but it shows how a little knowledge of KDE internals can do almost anything you want :-). Here goes:

We create a new "Session Type" for each tail command we want to run. I couldn't see a GUI-based way to do it, but the commandline way isn't very hard: Just put a tailn.desktop file in ~/.kde/share/apps/konsole/ with the following content:


[Desktop Entry]
Encoding=UTF-8
Type=KonsoleApplication
Name=Tail command n
Exec=tail -f /path/to/somefile
Cwd=
Tips=false

Repeat that for each command you want to run in a tab. Now (after running kbuildsycoca, or restarting KDE), you can use konsole's session menu to start tabs for all of these commands. The command will run in its own tab, and on logout/login, the tabs (and commands) will be restored :-).

Need a title

2005-09-27T23:45:00.000+01:00

I'm tempted to try to beat Rainer in the "most delayed report about
akademy" post, but I'll let it suffice to say that akademy was great
fun: Málaga's a great place, and the organising team did a brilliant
job of keeping everything running smoothly. The workstations in the
hacking rooms were particularly useful for running tests on the whole
of the KDE documentation, which I didn't have the hard disk space to
check out on my own machine (on which more later).

As well as being fun, it was a really productive week for the docs
team. I promised not to turn this post into an akademy report, so I'll
just link to the
one I wrote up for kde-doc-english. Despite getting plenty done,
there's no shortage of tasks left to do: if you have any proficiency
with writing, LaTeX, XSL, PHP or C++, we could use your help. Get in
touch with kde-doc-english@kde.org or with me directly (phil AT kde
dot org), and we'll suggest ways that you can help us improve KDE.

If you're a writer or maintainer of a document in KDE (or even the doc
writer for a 3rd party app), you'll find Frerich Raabe's
KDE docs
sanitizer useful. Give it a KDE docbook document, either by upload
or by giving the URL, and it will point out any mistakes in either the
DocBook markup, or in the little quirks that we require for KDE
documentation.

Quick tip: In the URL box, put a link to the document in
websvn, then bookmark the page. By going to the bookmark, you can
quickly recheck the document in SVN.

Some other miscellaneous fallout from akademy: I've joined the eV,
written some promo stuff (ok, so it wasn't much, but it feels like a
big step), offered my limited skills to a usability mini-project
(improving whatsthis help), and been invited to a RL KDE meetup. I
even did some actual writing of docs! At least life's not boring...

aKademy: Me three! (or, "Argh!")

2005-08-30T11:50:00.000+01:00

Apologies to those reading on Planet KDE for the blank post - either the blogger editor or my checkout of Konqueror managed to eat my whole post. Let me see if I can remember it...

My fourth day at aKademy, and it's shaping up to be a good one. Aaron and Waldo were definitely worth getting up for, giving a useful and entertaining (of course!) presentation on "Marketing for Geeks." Their ideas were fairly simple, but important. I think we can take a lot of it on board in the docs team, or more specifically, the projects that go on "around" the docs team - for example, the Features Guide.

Next up, Rainer presented his work on creating multimedia presentations from desktop captures. This has great potential for documentation - descriptions of actions that go "click on this, then on that, then enable the other, then ..." can be wearing both to write and to read (see, for example, this section of the userguide which I wrote). Showing a direct demonstration is a much better option for the user. When the technical issues are ironed out (and most of them are, as Rainer demonstrated), this technology should certainly be able to find a place in KDE docs.

The "aKademy appreciation awards," a new idea from Brad Hards, were presented straight afterwards, in a well-attended lecture theatre. It was great to see recognition for the docs team, with Lauri taking away (in spirit, at least - she hasn't yet got here) the award for non-coding contribution. Certainly well deserved: Lauri's knowledge of both the community and technology of KDE, and all the work she puts in, much of it in backstage jobs that are invisible to most people, are invaluable both to the KDE project in general and the docs team in particular.

With all that already done, there's plenty left to do for the rest of the day - Lauri arrives sometime soon, so docs work will probably start in earnest. There's PDF generation work to do, along with, I expect, an "invitation" (arm-twisting :-) to write another aKademy day report. I want to chase up a few people, and try out some of the tools Rainer demonstrated. Should keep me busy.

aKademy: Me too!

2005-08-30T11:09:00.000+01:00

End in sight

2005-07-15T16:48:00.000+01:00

The hours I've sunk into the second take at PDF generation are beginning to pay off. I've got most applications' docs in kdebase, kdepim and kdenetwork to produce some sort of PDF output, even if it's not completely correct. Since the last time I played around with this, we've got a new system for the DocBook -> LaTeX -> PDF conversion, namely dblatex. It has the enormous advantage of being actively maintained, and the maintainers have been really excellent in responding to the bugs, problems and quirks that I've found.

So, I'm now at the stage where it's worthwhile working on the formatting of the generated documents. I think there could be some improvements to the default formatting of the PDFs that dblatex produces, and it might be nice to have a little bit of branding - a few 'K' logos here and there, etc. Here's a short example (Klipper) of the PDFs we're generating, and a longer example (Userguide).

If you have the XSL, LaTeX or artistic skills to help, please get in touch with kde-doc-english@kde.org or with me directly (phil at kde dot org).

2005-06-29T20:39:00.000+01:00

It's been so long since I last blogged that I don't know what to include and what to leave out. In case anyone noticed my absence from IRC or mailing lists, I should say that my disappearance was, like so many others', due to exams. Not having a computer in my room really makes revision go a lot better :-).

I bought my plane tickets for akademy a couple of days ago. I had to resort to phone booking, since bmibaby's website seems to be so broken that it didn't even work in IE. Still, it's done now, so I'll be there in Malaga for the duration of the conference. It should be a lot of fun, and with the experience I gained from last year's conference, I should be able to get a lot done too.

Among the people I hope to meet at akademy is Evangelia Berdou, who, as Thomas Zander wrote, is doing research into aspects of co-operation in open-source, with KDE and GNOME as case studies. I had a telephone interview with Evangelia on Monday, which I was slightly hesitant about, since it was intended to deal mainly with the Quality Teams, and I haven't really been that deeply involved with the Quality Teams. (I follow the mailing list, and try to help where I can, but I haven't done much of the wider co-ordination work). As it turned out, I babbled on for an hour and enjoyed myself a lot more than I was expecting. I think I drifted off the topic a little at times, but I hope some of what I said will be useful for Evangelia's work, and, in the long run, KDE too.

In the world of documentation, I'm trying to make some inroads into our todo list. Rainer Endres' excellent new docs.kde.org front- and back-end for docs.kde.org will help with one item (linking between docs), and I've just started discussions with the author of dblatex, a tool which we plan to use for the creation of PDFs of the documentation. Using an actively maintained system should mean we avoid hitting the brick wall that was eventually going to come our way with db2latex, the system I was experimenting with a few months ago.

And of course, I haven't gone the last few months without a little frisbee: I managed to get onto the university first team, thanks to the loss of a few key players, and played the annual Oxford vs Cambridge varsity match, this year held in Cambridge. In sweltering temperatures, we managed to take the match 14-7, and I even made some nice defensive blocks. I also found out that Sander Koning, of kde.nl fame, is a fellow ultimate frisbee player, so much throwing of discs should take place at akademy :-)

De gustibus non est disputandum

2005-06-01T22:47:00.000+01:00

So it doesn't really have much to do with anything, but I completed the Times crossword yesterday - first time I've finished one of the daily ones. Worth a blog entry, I think.

And exams will be over in 2 and a half weeks, after which time I won't feel guilty about spending several hours doing crosswords instead of learning...

TW3

2005-05-10T17:42:00.000+01:00

Well, this really was the week that was. Last weekend, I managed to juggle two separate visitors to Oxford, despite them turning up at more-or-less the same time, and the later one coming on about 12 hours' notice (hi George!).

Wednesday saw me in a state of nervous tension all day, looking forward to the final of the Oxford colleges ultimate frisbee spring league. We were quite chuffed to get that far, and the opposition were looking good. To keep things interesting, I had a tutorial immediately before the match, which ended up being relocated about five times that afternoon, and then resulted in my finding out how little I know about atomic physics (with exams in six weeks. Argh!). Still, it was a good way to get fired up for a match in which we knew we needed to play hard to have any chance of winning.

Losing a player to a sprained ankle in the warm-up probably isn't the best way to start when your team has about 10 people on the squad and theirs has nearer 20, but that's the inauspicious way we began our bid for victory. It could only get better :-).

So, to the game. This must have been the closest and most hard-fought game of Oxford college ultimate that I've ever seen. For every point we scored, they responded. We had all the clichés, straight from a Hollywood sports film: neck-and-neck in points all the way, big catches, big defence plays saving us from conceding points, celebrations, and to top it off, the match went to sudden death. One point to determine the champion

And I scored it!! Woohoo! It's such a weird feeling watching an incoming disc, and thinking "If I catch this, we have celebrations, and if I drop it, everyone comes over and kicks me." So I caught it, and I've been on a high since. :-).

The rest of the photos are online too, if you're interested in that sort of thing.)

To top it off, it wasn't just a great game in terms of competitiveness: it had great 'spirit' too. Playing in such a close game that's self-referreed, and having almost zero arguments can only make one feel good about the world. And of course, after the match, we had the requisite silly games (known as "calls") and went out with our opponents, and most of the sizeable crowd who had cheered us on, for a drink.

Ah, good days. And that's to say nothing about my birthday yesterday...

This post Certified 100% PDF-Free(TM)

2005-04-23T22:29:00.000+01:00

So, after a small diversion to watch a slightly amusing troll ply his trade in #kde, I got to work on reviewing the tips database for ktips. Unfortunately, it seems not to have received much love lately, and there are stacks of cool features of KDE that aren't advertised there. I also want to plug the docs a bit with relevant links in the tips. Seems logical too.

First step was to go through the existing tips, and check them for accuracy and usefulness. I was pleasantly surprised to find that, modulo some changes in GUI texts, even the tips dating back to 2.0 days are still relevant. I guess that shows that the KDE framework was useful when KDE was started, and still is now, or something. I'm sure one of the more astute bloggers on planet KDE could come up with an analogy involving trees to illustrate the point more elegantly :-).

Next step was to think of what's missing. Fortunately, I had Fabrice Mous and Lauri on my side, so I didn't really have to think of very many myself. 45 minutes later, and I've got about 30 more neat features to write little tips for.

And, wow - I use KDE every day, yet there are all these features that I never knew about, like:

Hold Ctrl and scroll the mouse wheel in Konq to change font size

Hold Shift and scroll the mouse wheel for fast scrolling in any app

Middle mouse button on desktop for a window list

Plus a few that I knew about previously, but which still rock:

Web shortcuts in Konq

Konq's image gallery handling - the photobook plugin, and the image gallery creator.

Ability to use 'servicemenus' to modify various context menus

So now I have a big list of features to write little tips for, and the need to find some time to do it in. Hrm. There are a few more issues to look at: Most of the tips relate to apps included in kdebase. I guess there's no reason they shouldn't also include apps from all official KDE modules, but I guess I should check with core-devel.

And now Lauri has me reading the Epic of Gilgamesh (or "Gigglemesh" for any 5-year-old readers)...

More PDF...

2005-04-17T18:24:00.000+01:00

Apologies to anyone who downloaded the PDF generation tarball yesterday and found that it didn't work. My fault :-}. The updated version should work better. It does a couple more things - centres images, gives them a little padding, and gets rid of all the blank pages. For examples, see the Konqueror docs or The User Guide as PDF. As before, more testers are especially welcomed - thanks to mikmak on #kde-devel for pointing out some problems. If you're familiar with XSL or LaTeX (especially if you're a LaTeXpert), I'd love to have your help; get in touch at "phil at kde dot org" or on #kde-docs on irc.freenode.net .

And, for those interested in such things, I'm back at Uni again. So 8 weeks of revision and frisbee coming up. At least it won't snow this term when I'm out playing :-).

PDF Generation

2005-04-15T19:47:00.000+01:00

PDF generation of the KDE docs is something we get asked for every so often, and it turns out to be less easy than you might suppose. There are quite a few tools around that will do the conversion in one way or another, all with their own problems. In the end, we've settled on the db2latex XSL stylesheets to get LaTeX output, and then pdflatex for the PDF. It took some tweaking of the XSL and a Perl script to wrap around it all to fix some of the problems, but we seem to have fairly good-looking output.

And of course, just as I write that, Lauri shows me the output that her version of libxslt produces, which is, erm, less nice: the table of contents has made its way into the title. Great. I guess I'll have to update my libxslt at some point to test.

So, the next step is some more data points, and some testing. To that end, I've put the tools up here. Download it, unpack, and follow the instructions in the README. Hopefully it should work, giving you a nice PDF file of some KDE document. (The Perl code is really not excellent; feel free to send me improvements :-)

In other news, I've joined the legions of text-message obsessed adolescents by (reluctantly) getting myself a mobile phone. So if u c me usng txt slng, KILL ME IMMEDIATELY!

DCOP and Pretty Eye Candy

2005-03-23T11:37:00.000Z

After a little discussion on #kde about a programme that no-one could remember the name of, but which produced a cool "slowly changing the background colour" effect, I decided to have a go at creating my own version with Perl and DCOP. Turned out to be pretty easy, with the hardest bit being working out how to calculate what colour to use next.

So, here it is: http://users.ox.ac.uk/~chri1802/stuff/chbg.pl.

The actual DCOP call is just one easy line, and most of the code is twiddling the RGB colour value. Doing it with HSV would almost certainly be cleaner - I'll look into it sometime.

Lauri pointed out that it's a nice as an example of general DCOP scripting, so I wrote it up and put it in the User Guide. The prose isn't great, and it could do with some screenshots etc, but comments, suggestions and improvements are welcome.

And on a similar note, does anyone have any other nice uses of the KDE command line tools? Between kreadconfig, kdialog, dcop, kstart and a little scripting glue, we've got a powerful framework that could do with more extensive documentation and promotion. Rich Moore has already written some info on kstart and ksystraycmd, but any more ideas would be gratefully received.

Snap, Crackle and Pop

2005-02-26T19:25:00.000Z

Uni work has kept me away from getting much KDE stuff done recently, but I got a chance this weekend to finally cross an item off my todo list: I've finished the KDE Documentation Primer, which is an amalgamation of all the material we have for potential new contributors into one document so it's all in a nice order. Previously, we had the same problem that Adriaan's UofKDE idea addresses: we had good documentation, but no indication of what order to read it in, or what's important and what's just secondary. Hopefully the Documentation Primer addresses all that, and will be a useful resource.

I made my first foray into the world of promotion this week, somewhat accidentally:


[Riddell] any suggestions for how to write an interesting dot article 
          around that beastie? [bug 100,000]
[PhilRod] Riddell: comments on how the bug system works, that you can 
          report wishlists, that people should help with triage, and 
          how to report bugs effectively?
[Riddell] PhilRod: fancy writing such an article?
[PhilRod] Riddell: I knew that was coming :-)

And so I ended up writing a short article about the bug system. It seemed to get a fairly good reception from the people who gave it a quick proofread before I submitted. I'm not sure how many readers on the dot took it to heart though.

And on the topic of promotion, we (well, really canllaith and a few others on IRC) have some nice ideas about ways of making potential and actual users aware of the cool features and technologies in KDE. They're RL-bound at the moment, but it'll be interesting to flesh out some of the ideas and see where they can go. We'll also have to bring in the promo team to get their knowledge and experience. I'll leave Jes to expand on her idea, since I wouldn't want to claim credit for it, but it's exciting and I'm looking forward to realizing it.

Crosswords, accesskeys, frisbee...

2005-01-15T20:37:00.000Z

In other news, there are a few things to report, most important of which is that I completed a Times cryptic crossword, for the first time ever! My life is now complete, or at least that little black-and-white-squares shaped bit of it. :-)

I've been contracted by George Staikos to work on the documentation of Kst. For those who don't know (and for the sake of random rambling...), Kst is a data plotting and viewing programme. What's particularly exciting about working on it is that it's used mainly by research physicists for several astrophysics experiments, some of which link in with what I was studying last term. I've got a few ideas for ways of improving the already quite good documentation, but I'll need to put some more hours into it that I have over the Christmas period. Hopefully I'll have some time this week to get a bit more progress...

...That despite term having started again, and plenty of work looming on the horizon. At least it means a chance to play ultimate frisbee again. I didn't realise how much I've missed running around a muddy field shouting at people and throwing a plastic disc.

Oh, and how could I forget, the new User Guide made it into kdebase, so it'll be in 3.4. W00t! Take a look at it, suggest new sections, write material for the missing sections, or just admire its beauty :-).

Also, if you know any frequently asked KDE questions that aren't in the KDE FAQ, send 'em along to faq@kde.org. canllaith is looking forward to receiving them (I think).

Cool (kinda) new doc-related feature of the week: Bring up a KDE handbook in Konqueror or KHelpCenter, and hit Ctrl to enable accesskeys. You can now navigate the document with 'h' for 'Home' (the table of contents), 'n' for the next page, 'p' for, well, you get the idea. You'll need CVS HEAD from at least today for the full experience - previously we only had 'p' and 'n'. The online version on docs.kde.org will have them too, just as soon as I check with the accessibility team about following the www.kde.org standard.

Hear, hear

2005-01-15T20:07:00.000Z

annma writes:

I know the doc team is doing a tremendous job, what lacks is only outside involvement [...] Please, just write a few lines about your preferred program and send it to me, I'll include it in the manual!

The same goes for any other KDE apps, not just the kdeedu module: we'd really welcome the developers getting more involved with writing docs for their applications. Users too - if you notice something missing in the existing KDE docs, consider writing a bit. It doesn't need to be a full manual, and you don't have to commit to maintaining it. Most importantly,

You Don't Need to Learn Docbook!

Obviously, it's great if you have the time to learn it, but we'd rather have content in plain text, which we can add markup to, than no content at all.

If you're a user who'd like to help, drop an email along to kde-quality@kde.org, and they'll help you find an application which you'll enjoy working on, and give you some tips to get started.

If you're a developer, you could just take a look through the existing docs for your application and see what's missing or out-of-date there. If you don't have time to update the docs yourself, file a bug in the 'docs' product, with details of what's changed, or what's missing. It makes it a lot easier for us to update the documentation if we already know what needs to be done.

Lecture ends. :-)

Nationality

2004-11-22T21:38:00.000Z

Not much happening KDE-wise in my part of the world. HEAD is broken, and I've just done a big ol' system upgrade to FreeBSD 5.3, with associated tidy-up still ongoing. 'Twas probably a bad idea to do it when term is still on, especially since the Christmas holiday is so close, when I'll have plenty of time for such things. Anyway, for lack of anything better to write about, I thought I'd summarize my nationality, for anyone who cares, since it's come up in conversation a few times on IRC, and makes a nice little conversational gambit.

If life were simple, I guess I could just say "I was born in Cardiff, in Wales, so I'm Welsh." But that would spoil my little gambit, and it's not quite correct anyway. The first fly in the ointment is that neither of my parents are Welsh: my mum is English, and my dad Indian (although he was born and brought up in Uganda, and has never lived in India). I don't suppose it's too complicated so far, but having a Portuguese surname, when (I assume) I have no Portuguese heritage at all, makes for a little more confusion. When I was applying to universities, I went to an open day at Imperial College in London. On finding the appropriate person to talk to, I told her my name, and was greeted with a stream of something that wasn't English. My brain must have been on form that day, since I managed to realise fairly quickly that she was asking me if I spoke Portuguese. Alas, not a word of it, I had to admit.

That's about it, although if I need a quick answer to a question about nationality, then I'm British - my passport says so :-). Still, it's nice being able to pick and choose between three countries when finding a sports team to support...

Well, KDE is pretty international, so I guess someone can trump me on 'number of plausible nationalities', so go for it! I'd be intrigued to see how many nationalities can be crammed into one person. :-)

'did physics; played frisbee; ate; slept'

2004-11-01T19:06:00.000Z

OK, so quoting myself in blog entries is probably very bad form, but it's a pretty accurate reflection of what I've spent my time doing in the last few weeks.

I did find some time for KDE stuff though. Aside from hanging around on #kde giving everyone one of my three or four stock answers, I managed to finish up all the stuff for the docs competition. The winners were decided on, they were notified, and everyone's work was marked up and merged into the User Guide. That takes it to 30,000 words, in terms of 'wc -w' output. I'm so proud :-).

Hanging round in #kde has had its upside too: canllaith and StevenR have submitted some great content and screenshots for the User Guide, after my requests for help in the channel. They also demonstrate that it's really easy to get into helping with KDE in general, and docs in particular. Hopefully we're providing quick satisfaction too - I've been updating the online version of the Guide
with each commit, so everyone can see their work as soon as possible. With just a little more work, we'll be ready to move the Guide into kdebase.

I also played around a little bit more with PDF generation. I tried FOP along with the DocBook XSL FO stylesheets, which works fairly tidily, but has the problem that FOP is a Java app, and so it's not really appropriate for distributing KDE stuff with. The other thing is that the output of the DocBook FO stylesheets doesn't seem all that great-looking. I'm sure it's quite easily changed with parameters, but it doesn't seem worth it when the next stage (FO -> PDF) lacks appropriate tools.

That brought me back to db2latex (and dblatex, due to a typo in the location bar). I've got a workaround to the main bug that was holding it back, and I even have a vague idea why it works. There are still a few issues to be ironed out, but hopefully they're more minor. If you know anything about XSLT or quite a bit about LaTeX and want to help, get in touch with kde-doc-english.

That's about it for KDE stuff. Here are some ultimate frisbee photos, if you're so inclined.

File Under 'Miscellaneous'

2004-10-13T21:40:00.000+01:00

Time for a long and rambling blog entry, I think. Term has started, so for the next 8 weeks, any blog entry I write will look like 'did physics; played frisbee; ate; slept'. That's pretty dull, so I'll just braindump now instead.

It's good to be back into the swing of uni after a ridiculously long holiday. I can't get anything done without some kind of routine, so I expect to get far more done in the next 8 weeks than in the previous three months. My new room is nice and large, but all the quirks of the rooms here are close at hand: the cold tap dispenses hot water periodically, the floor is nowhere near level (I think I'm sitting at the uphill end), and I can hear the cathedral bells quite clearly (at 9:40pm. Why are church bells ringing at 9:40pm?!).

Of course, such a scene of pastoral bliss couldn't last long, and it was quickly and cleanly spoilt by having to do lab work. Apart from the usual problem of doing a practical when having no clue about the theory behind it, we had to use computer programmes written by physicists. Perhaps using KDE has spoilt me, but using a programme that deliberately core dumps when the specified output file already exists wasn't a pleasant experience. Still, once the grunt work was done, the results were fairly interesting (calculating ages of globular clusters, since you asked).

On the KDE front, I haven't really done anything much. Competition judging is going on, but has turned up at exactly the wrong time for Malcolm Hunter and I (who are judging). Malcolm has been away, and I've started term. If anyone reading this has submitted an entry for the docs competition, we're doing our best to get the results as soon as possible. Thanks for your patience.

Also, I copied my web stuff from my university space to fruitsalad.org. Anything that started with http://users.ox.ac.uk/~chri1802 can now be replaced with http://people.fruitsalad.org/phil. I'll move the stuff off the uni space when I get round to it.

Pat self on back

2004-09-29T17:11:00.000+01:00

I was looking at webcvs the other day and found out that the new User Guide was first added to CVS about 5 months ago, and it already has 23,000 words (according to 'wc -w'), and makes over 100 pages in PDF. So here's a pat on the back to everyone who's helped - thanks muchly. And don't forget the competition: there are still a few days to get your entry in :-)

Documentation with Style(sheets)

2004-09-24T22:35:00.000+01:00

Played around with the DocBook->HTML stylesheets and their many parameters. I managed to turn off the messy inline CSS that's been in the HTML output since (I assume) forever, and get a much more manageable table of contents for the user guide. Here's a super-mini HOWTO on customizing your KDE documentation:

Create a file with the following content:


<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

                version='1.0'>



  <xsl:import href="KDEDIR/share/apps/ksgmltools2/customization/kde-chunk.xsl"/>



</xsl:stylesheet>

but replace KDEDIR with your own $KDEDIR. Save it as, say, mystyle.xsl

Take a look at The DocBook Parameter Reference (from where I for the example stylesheet above), choose a parameter you like the look of, and add an appropriate <xsl:param> line below <xsl:import>. A neat one to play around with would be html.stylesheet: you can change the CSS stylesheet used by the output HTML to one of your own devising.

Repeat step 2 for as many paramters as you like

Run "meinproc --stylesheet /path/to/mystyle.xsl index.docbook" in a directory containing some KDE documentation, and view the resulting HTML

I think you can also do this in a more automatic way, and on a per-document basis, using processing instructions like <?dbhtml html.stylesheet="foo.css"?>, but I haven't tried it yet.

Meanwhile, I have to go back to being eaten alive by every biting insect in Cardiff...

Win win win!

2004-09-20T21:26:00.000+01:00

For those of you who don't read the dot, or just missed the story in the rash of posts in the last few days, we're running a competition. All you have to do to be in with a chance of winning some cool O'Reilly gear is write a page - just one page - for the new KDE User Guide. The competition's open to all, and you don't need to know DocBook - just submit your entry in plain text. The dot story has all the other details.

Taking off my promotional hat for a moment, I'll mention the competition we ran at aKademy, which was won by Waldo Bastian. His "KDE for Admins" notes are currently being merged into the User Guide, and look set to be a huge boon for the KDE documentation. Hopefully we'll get lots of entries of that quality for this competition. So get writing!

Glossary, FAQs, scripts

2004-09-18T14:56:00.000+01:00

Plenty happening on the docs front at the moment, if a bit slowly:

I've done some work towards having a KDE-wide glossary. The idea would be to have one big glossary, and allow application manuals to include only the entries that they need. There are still some technical problems with this approach, which I should discuss with Lauri, or anyone else who knows.

The KDE FAQ is making some progress. I've summarized the plans for it on the wiki, and answers for any of those questions (or any other FAQ), are welcome. Thanks to Aaron for already doing so.

After Carlos Woelz mentioning the visual dictionary, I remembered my old, and not particularly excellent, preferred_forms script. I'm not really sure what to do with it. We have a handful of other scripts for checking various aspects of documentation files, but they're all not-quite-finished, and we haven't got round to it yet. They should make a quite comprehensive suite for ensuring tidiness and consistency across docs in the future.

I got my hands on Waldo Bastian's prize-winning notes on "KDE for Administrators", and started merging them into the User Guide. I've added DocBook markup to the first part, but it would also benefit from some fleshing out to go from 'notes' to 'documentation'.

2004-09-06T17:11:00.000+01:00

Well, as everyone else has pointed out, aKademy was great. I'll add my thanks to all those who were involved in organizing it - hope you've all had a chance to recover now that it's over for another year :-)

I thought I'd start the shameless plugging of docs stuff now. We had a busy week, like everyone else, and made some good links with the rest of the community. Some of the highlights were:

Discussion with the usability folks about improving KHelpCenter, with some great ideas, and hopefully an opportunity to get some payoff for all the effort we've spent in putting comprehensive markup in all the KDE documentation

Learning (by experience) that 'pizza peperoni' in German does *not* mean the same as 'pepperoni pizza' in English :-)

Getting some great ideas from Fabrice Mous about attracting and keeping contributors. We're trying to put them into action now, starting with discussions with the Quality Teams, and a new 'Welcome Pack' for people offering to help with doc writing.

You can find a more comprehensive list at http://wiki.kde.org/tiki-index.php?page=Documentation+Team+Ideas. If you want to help (and we're crying out for new contributors), drop us a line at kde-doc-english@kde.org.

Ana Ng and I are getting old...

2004-09-04T17:09:00.000+01:00

Hrm. I suppose now I have a blog too, so I get to join the world and its dog in sharing my random thoughts with anyone bored enough to listen. Don't expect to find much here apart from shameless plugs for things we're doing in the KDE documentation team. Lots of ideas from aKademy, now's the time to put them into action.