Koos Vriezen 

Some time I'm thinking about ways to get rid of the many string comparison when playing a SMIL file in KMPlayer. The flow of a movie is mainly written in tags and attribure values. These documents have hardly any textnodes, so tags+attributes are about halve of the content, remaining is then the attribute values. So sharing these strings for tags/attributes would also be a great memory saving, making the DOM grow at 50% speed. Read More

At Fosem when asked about motivation developing OSS, it's learning in my case. I started the XML engine in KMPlayer when in my previous job, between projects, I was reading some docu's about JavaEE, and getting bored reading I started thinking about an implementation. Now there where some bug reports about not supporting certain links, that turned out to be crappy ASX/broken XML files, I started writing a failure proof XML parser, replacing pre parsing hack to make QDom happy. It grew a bit beyond former expectations to also support more XML playlist like XSPF, podcast and SMIL. Now SMIL is big, so that will keep me busy some time, but I just fix/implement real live links. Now SMIL is a bit old fashion and I believe to be super seeded with HTML+CSS+JavaScript or flash. Nevertheless, moving KMPlayer in other directions than the other KDE mm-players, I kept on working on it. Latest edition got the cairo painting implementation. Painting was always crappy till then and I was delaying the real fixing to later, eg Qt4 has this nice graphicsview.. Anyhow, my current colleague Frerich Raabe introduced me with the visitor pattern that, at first looked a bit inefficient, has this nice benefit to separate a particular functionality in a single class. Together with the porting of KMPlayer to the Internet tablet and a thread on the mailing list about cairo compared to other painting engines, this was a nice way to learn about the behaviour of visitors. Two visitor classes are now used, one for painting and one for mouse events. And yes, it really is a cleanup. Read More

Mentioned in an older blog, I ported KMPlayer to the Nokia770. Given that the GUI of a full KDE desktop and from this device are so different, I doesn't made sense to make fake QWidget classes for this port. However for utility classes like QString and KURL it did make sense. This weekend I ported the RealPix support to the N770 and benefiting greatly from these wrapper classes. The diff between these source files are no more than some include statements and lines where QString -> String. Read More

What should one do if someone spreads FUD about a part of open source. Lets try the "why?" question. So one bashes qt on #maemo, channel for this GTK based platform used by the N770. Names are mangled if not me. Read More

Being in the N770 developments program and their great SDK/emulator, I really couldn't resist to try some programming for myself. Obvious choice is of course a port of kmplayer. The SDK is great and has both an i386 and arm target. The arm target uses qemu and is not capable of running GUI clients, but does run the console stuff, like configure scripts!!, this way. Having a 220MHz arm + 220MHz dsp dual core CPU and 64Mb of memory makes this device something that was standard about 8 years ago. The dsp chip adds additional video/audio decoding. Nokia added herefor a few closed source gstreamer modules. I haven't been able to pipeline those properly so that they would play video. But I guess that should be possible, also because I've managed to get mp3 playing with it. Given a pda with wifi/bluetooth 800x480 px sreen and 64Mb RAM/128Mb flash plus rs-mmc extention slot, I makes sense to go for a full blown x-server. They've chosen for gnome, though stripped down versions. Actually I don't know what's gnome about this because it mainly gtk/d-bus/gstreamer/gnome-vfs/.. stuff plus a so called hildon application framework (but what do I know on this subject). I don't think there is an alternative given this hardware other then using framebuffer instead of X. Read More