OSDW miniconf

Caught the start of the second day of Aaron Seigo?s presentation, a high?ish level overview of the KDE libraries. There was a brief pause before he turned up; for someone who?d been slaving over the karaoke microphone all night, though, he was in top form.

The parts of the talk that I caught dealt with using plugins in KDE apps. Whenever I've flirted with KDE development in the past, I?ve never really got KParts, but they make a lot more sense know. In particular, the KTrader system seems really nice. Using this you can say to KDE ?give me all the plugins that can edit text?, it?ll give you a bunch of plugin factories back, and your golden. Brilliant.

He also went into the details of the guidelines KDE uses to maintain binary compatibility. As a user, I?ve always appreciated this, but never been in the situation where I had to prevent breaking the interfaces as a developer. Basically, you really truly always want binary compatibility ? breaking it annoys the developers (who end up having to do extra work), annoys the users (their plugins break) ? you just don?t want to go there.

The rules he listed seem straightforward ? they basically come down to don?t change how the class looks (i.e., don?t change the vtable size, don?t change the layout of the class etc.), but the most interesting thing he covered here was the ?d?pointer? ? a pointer to a private class, which lets you (essentially) add private members to the class without changing the memory layout. You can see an example in pretty much any KDE class, such as KEditListBox.

Of course, this matters less with the programming languages I use these days (with the notable exception of Objective?C, which (I believe) dodges the virtual member problems thanks to message passing, but probably still has the ?don?t change the class layout? thing, although I haven?t verified this.

We broke for coffee here; I wandered back to the gnome.conf.au miniconf instead.