A week with norwegian Trolls

Two weeks have passed since I was in Norway, but I wanted to let you all know about it...

Trolltech sponsored and organized a meeting in their offices in Oslo to review the Solid and Phonon APIs and to get Trolltech on board to look into support for other platforms. It was a week of very fruitful discussions and hacking.

The typical day looked like this:

Get up at 7-8 (or later if you couldn't finish hacking the night before ) and go for the best breakfast in town. Then walk to the office (just a few minutes walk) and start hacking until the office fills with all the right people that want to do Phonon/Solid API reviews. We met in the room labeled "Learning" where we were seated in comfortable bean bags or sofas looking at the header files projected onto the whiteboard. And then everybody was free to ask questions:

• Why is that function there? Why not make it private?


• Why is this called AbstractSomething if the user of the API is not meant to reimplement the class?


• Is this class necessary?


• Can we have a better name for "..."? Are there similar methods in Qt so that we can keep the naming consistent?


• What applications will use this? Only one or two?

A very useful concept when deciding what belongs where was to think about "platforms". Where in this case KDE is the platform - not Linux. I have to add a small explanation here as Aaron just ranted about other people telling that the platforms are GNOME and KDE and not Linux. I think both views are right, but only depending on the issue you're looking at. The platforms an ISV should have to think about are really only Linux, MacOS and Windows. But as a library developer, who is working on creating a lib to make the lives of ISVs easier, you have to think about the integration into the desktop and that is either GNOME or KDE. Ideally the ISV then writes the application with Qt, compiles one Linux binary and that one integrates as good with KDE as it does with GNOME.

Anyway this kind of API review was really good for Phonon and Solid and more APIs could benefit from such work. Too bad that we don't have the time to do it for all of kdelibs

The most invasive change in Phonon was the removal of all MediaProducer classes except MediaObject in favor of an additional class MediaSource. So instead of deciding whether you need a MediaObject, MediaQueue, ByteStream or AvCapture object you now take a MediaObject and call setCurrentSource(MediaSource). MediaSource is just a simple class with implicit constructors so you'll be able to write:

This will instruct Phonon to play the local file "file.ogg", then continue with the embedded Qt resource file "pling.ogg", then play file2.mp3 over http, then playback an audio CD, and then "file3.ogg" over sftp (using KIO). It will try to do gapless playback by default, though that might not work correctly with the current xine backend since xine-lib doesn't provide pre-buffering for the enqueued media sources. For local files gapless playback works like a charm already, though.