Christian: GStreamer has historically had closer ties to GNOME than KDE; did you feel the GStreamer community accommodated and welcomed for you as a KDE developer?
Mark: Oh yes, the GStreamer community has been very helpful and quite friendly in general. That's one of the big advantages of GStreamer - it is a true community project. On IRC you can basically get help 24/7, and talk to the core developers personally; This way problems are usually sorted out quickly. This year Christian and Wim from GStreamer attended our KDE conference "aKademy", which was pretty cool, as we could chat a bit in person, have a few pints and discuss multimedia stuff.
Max: I never once felt GStreamer was a GNOME specific project. And even if it was that wouldn't have stopped us from using it in amaroK.
Christian: Multimedia is a field riddled with US software patents. What are your thoughts on the dangers facing GNU/Linux/FreeBSD multimedia and its developers from patent holders desperate to hold on to their monopolies or just milking the unwary developer?
Mark: Like most open source developers I believe that software patents are a really bad idea, and I'm afraid of the consequences in the long run.
Max: As a young European developer who wants to make a living from software, patents scare me a great deal. I feel that patents are generally stifle innovation in all industries bar a few, notably industries where the cost of research is so high that innovation would not occur at all without the patent incentive. Otherwise I feel that the incentive to make money is sufficient for most creative people. I am already put off development now and in the future due to the very idea of software patents. I can only hope the world sees sense.
Leinir: Quite frankly, I am scared. While the US patents have no influence at all on e.g. amaroK, since the development is hosted outside of the US, it will mean a lot of work will have serious problems being accepted in the US, and while you might argue that that is only one part of the global market, unfortunately it is a very large part of it. So I am very much hoping that the US courts will interpret the laws in a way that is beneficial to open source development.
Christian: You have been working on both a crossfade plugin and a kioslave plugin for GStreamer how has that been?
Mark: KIO support what relatively simple, but crossfading turned out to be a real beast and took a long time to get right; it drove me to the edge of insanity. I was starting to throw my food around the room and talked to the carpet, it was that bad. Don't try this at home, kids! To summarize, getting the basic design right was rather straightforward, especially with the generous help from Thomas Vander Stichele on IRC. amaroK was the first application to implement crossfading with GStreamer, so I did not have an example source for guidance. The hard part was to work around all those little threading related quirks in GStreamer, as the crossfader must use two threads simultaneously, and exchange parts of the pipeline while it is running. One must be very careful not to produce audio dropouts and noises while new tracks are started and stopped. Fortunately, in the end it all worked out, I was quite happy with the result, and I had learned a lot about GStreamer programming.
Christian: What features are you most happy about in GStreamer today and what are you most unhappy with?
Mark: I'm happy with the general architecture of GStreamer (the core), its flexibility and the ever growing amount of cool plugins. One of the points I'm not so happy with is IO support. For accessing non-local protocols like http (for streaming) or ftp, all current GNOME based GStreamer applications relies on the gnome-vfs plugin, which depends on GNOME libraries. This is, of course, not an acceptable solution for KDE applications. So there were efforts by myself and others to offer KIO support, which is the KDE equivalent to gnome-vfs, but unfortunately KIO does not cooperate very well with GStreamer's design, in the sense that KIO requires an qt eventloop, so the current solution is to run the kio plugin within the amaroK eventloop which I feel is a bit ugly.
In the long run I think it would be better if GStreamer offered its own integrated IO subsystem, which would not depend on GNOME or KDE, or maybe that both gets replaced by a freedesktop IO subsystem.
Christian: What are your upcoming plans for amaroK?
Mark: One of the features we are working on is a flexible plugin system, which should allow to extend amaroK in useful ways. For instance once could add a new browser plugin, perhaps for accessing portable music players, or playlist enhancements. My vision is to make the plugin interface accessible for multiple languages, not only C++. I think it could be a very attractive option to program a plugin in scripting languages like python or ruby, which would allow rapid development without long compile cycles.
Leinir: More of the same, really... Helping with cleaning up the interface, trying as well as possible to keep with the HIG and other specifications put out by the KDE usability team. Also, I am currently helping with the new layout for the Context browser, which will eventually mean that it will be possible to theme the Context browser very easily, simply by using CSS. There is a screenshot of some early development of it in the amaroK In Development screenshot gallery.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.