Of course, this entry will talk about xine-lib.
First of all, a note about what I’m trying to do with contributed code in xine-lib for 1.2 series. As I said already, my ffmpeg_integration branch, which is one of the two branches I merged to get the 1.2 branch itself, was born to allow using FFmpeg without changing its buildsystem, and putting it in a contrib/ subdirectory instead of mixing it with xine sources.
Well, as I’ve now started working on providing also some Doxygen documentation, I’ve seen that this is useful also for other projects that are imported in xine-lib, so that I don’t have to blacklist one by one the directories and the files that are not to be parsed for Doxygen generation.
In xine-lib-1.2 hg tip you can now find libmpcdec (that replaced libmusepack) in contrib/libmpcdec/ rather than having it together xine’s actual code (the decoder plugin code) inside src/libmusepack/. I also updated it to the last version available.
Similarly I hope to move other code, like libmad and of course libdvdnav, that was recently taken over by MPlayer developers because of the unresponsiveness of the original development project.
It will take some time to complete all the moves, also because I’ll try to contextually update the code with the last version available for every project beside libmpeg2. This should be a breath of fresh air for xine 1.2.
Talking about FreeDesktop standards, as Darren already changed gxine to abide to XDG Base Directory Specification, he also added better FreeDesktop standard support in xine-lib for configuration and cache files. So right now I’m working on making xine-lib use XDG_CACHE_HOME to store the plugins cache instead of the hardcoded ~/.xine/catalog.cache, which also allows me to move more cache data out of my home directory 
By the way, why one earth the description of the permissions to use while creating directory (that is actually a quite logic 0700) is written in the «Referencing this specification» section ?
In the summer of 2003 I went to Europe and on several (17) occasions used this neat feature of my Canon camera that lets you line up images and create panoramas. Just load them on to your computer and stitch them together. Back then all the software that was usable was Windows based and I think somehow the few panoramas I did put together were lost.
This week I got something called
Hugin to work. In typical Ubuntu/Debian style
* several runtime deps weren't included and autopanog.exe (its Mono) was renamed to autopanog and no one told Hugin.
...anyways I got it to work. And it works pretty well, better then I remember before. When they messed up it was because I was taking these without a tripod.
Here are some of the neat ones:
You can see the rest at my
panorama photo set.
Friday, April 13. 2007
Just put up the announcement to amarok.kde.org regarding
Summer of Code. Its really great to do it for another year. Last summer I did the Amarok DAAP integration, this summer I'll be overhauling the playlist in Amarok. Refactoring the playlist is a project thats long overdue (its been talked about for at least 2 years!) and redesigning the playlist layout is just simply necessary for our vision for Amarok 2.0.
I was actually accepted for another project as well, a Phonon VideoLAN plugin. After learning more about VideoLAN, I was somewhat concerned that while it probably is a at-most three month job to do it, they may not be three
consecutive months as it might require some tweaking of VideoLAN to preform all the functions it needs to. Phonon is an impresively complete API, which makes it a bit scary for backend developers.
I still think a 'phonon-videolan' would be a great idea. VideoLAN is crossplatform, has an active development team and most importantly phonon-videolan would "live" in VideoLAN's repositories. At least in the long-run, it really makes sense to release phonon backends in sync with their respective multimedia library (as opposed to being in kdemultimedia, where they are now). And being part of their repo means the people who know VideoLAN the most would maintain it.
Luckily Jean-Baptiste Kempf is planning on doing it perhaps in the KDE 4.1 timeframe. He has to finish the Qt replacement first (which is looking good BTW). So best of luck to him - I promised to at the least "compile along" and test phonon-videolan when he starts developing it.