Amarok Blog

I remember first hearing about Autopackage 2-3 years ago and it struck a note with me. At the time I was new to Linux and hated RPMs and never had much luck with autotools (not much has changed with the latter or the former really ) So the idea of Windows-style installers was brilliant! I tried to get involved with the project but I rapidly came to realise I didn't have a clue when it came to all the important stuff I needed to know.

With time comes understanding, and now I realise autopackage isn't great because of the graphical installers. Many other projects have proved you can bundle a graphical installer, that compiles from source or provides a binary that is built in a "distro-neutral" fashion. I find their technology exciting, and I hope it will reduce the amount of time we have to spend helping people who are new to Linux getting amaroK installed.

amaroK could probably be autopackaged quite easily. We have 2 certain dependencies, KDElibs and Taglib, and it should be quite simple to make the detection scripts for those. The engines are loaded at runtime, and we can show helpful failure messages, like "Install xine-lib!" (well almost helpful). The biggest problem is our use of the STL. libstdc++ has no binary compatability (unlike KDE and Qt). So we have to basically build an autopackage for each GCC version (ouch), or remove as much STL dependence as we dare. Another issue is that most of amaroK has to be installed to a KDE prefix (Autopackage allows packages to be installed anywhere). But, at least at first, I will force installation to kde-config --prefix.

I don't think I'll make headway removing STL usage. People like the STL, I even like some parts of it So maybe we can just hope that things like std::vector are binary safe? Maybe.

Still this is an interesting new project I look forward to attempting.

I remember first hearing about Autopackage 2-3 years ago and it struck a note with me. At the time I was new to Linux and hated RPMs and never had much luck with autotools (not much has changed with the latter or the former really ) So the idea of Windows-style installers was brilliant! I tried to get involved with the project but I rapidly came to realise I didn’t have a clue when it came to all the important stuff I needed to know.

With time comes understanding, and now I realise autopackage isn’t great because of the graphical installers. Many other projects have proved you can bundle a graphical installer, that compiles from source or provides a binary that is built in a “distro-neutral” fashion. I find their technology exciting, and I hope it will reduce the amount of time we have to spend helping people who are new to Linux getting amaroK installed.

amaroK could probably be autopackaged quite easily. We have 2 certain dependencies, KDElibs and Taglib, and it should be quite simple to make the detection scripts for those. The engines are loaded at runtime, and we can show helpful failure messages, like “Install xine-lib!” (well almost helpful). The biggest problem is our use of the STL. libstdc++ has no binary compatability (unlike KDE and Qt). So we have to basically build an autopackage for each GCC version (ouch), or remove as much STL dependence as we dare. Another issue is that most of amaroK has to be installed to a KDE prefix (Autopackage allows packages to be installed anywhere). But, at least at first, I will force installation to kde-config –prefix.

I don’t think I’ll make headway removing STL usage. People like the STL, I even like some parts of it So maybe we can just hope that things like std::vector are binary safe? Maybe.

Still this is an interesting new project I look forward to attempting.

I remember first hearing about Autopackage 2-3 years ago and it struck a note with me. At the time I was new to Linux and hated RPMs and never had much luck with autotools (not much has changed with the latter or the former really ) So the idea of Windows-style installers was brilliant! I tried to get involved with the project but I rapidly came to realise I didn’t have a clue when it came to all the important stuff I needed to know.

With time comes understanding, and now I realise autopackage isn’t great because of the graphical installers. Many other projects have proved you can bundle a graphical installer, that compiles from source or provides a binary that is built in a “distro-neutral” fashion. I find their technology exciting, and I hope it will reduce the amount of time we have to spend helping people who are new to Linux getting amaroK installed.

amaroK could probably be autopackaged quite easily. We have 2 certain dependencies, KDElibs and Taglib, and it should be quite simple to make the detection scripts for those. The engines are loaded at runtime, and we can show helpful failure messages, like “Install xine-lib!” (well almost helpful). The biggest problem is our use of the STL. libstdc++ has no binary compatability (unlike KDE and Qt). So we have to basically build an autopackage for each GCC version (ouch), or remove as much STL dependence as we dare. Another issue is that most of amaroK has to be installed to a KDE prefix (Autopackage allows packages to be installed anywhere). But, at least at first, I will force installation to kde-config –prefix.

I don’t think I’ll make headway removing STL usage. People like the STL, I even like some parts of it So maybe we can just hope that things like std::vector are binary safe? Maybe.

Still this is an interesting new project I look forward to attempting.

I thought I'd list my plans for 1.3:

• Playlist refactor (essential first step)
  
• Playlist improvements! (me and seb will kick some booty)
  
• More integration of libvisual into amaroK. libvisual is really starting to rock and I want amaroK to be its flagship.
  
• Truly gapless track transitions (by preloading the next track; this may be foolish, since we can only predict the next track if you let the playlist choose, I'd like to play with it though)
  
• Support for some more interesting tags. All Taglib supported formats can have extended tags, so i want Disc# and Producer. We can support arbiturary tags too, but these two fit will with what we already have.
  
• Crossfade (again) + KIO Source for xine-engine
  
• libxmms-engine (I really need to knock this one out)
  

I'd like to stress, this is only what I plan. Other people will do more stuff! Eg ReplayGain.

People still ask for "plugins", but I think markey has done the best thing we can do with regard to plugins (the script manager). Because what people want are input plugins and output plugins and effects and visualisations! But we farm all this stuff out to other libraries. We could offer effects plugins, but this would be a lot of work and I don't think we'd get many plugins written. It's better to let people write them for GStreamer/xine/etc. as these people are extremely talented. We could still offer a C++ API that allows new browsers or something, and we might, but I think we're all scared of limiting ourselves by having to ensure plugins continue to work one version to the next.

I'm hoping muesli + co. will make removable collections a possibility (eg collections from other computers that are not always on, or from your portable-media-device, or maybe even your usbkey). Some people also have grand designs for changes to various interface components, though I haven't faith in all these changes as everything about the amaroK interface is one big compromise; not one of us is 100% happy with the interface, but other constraints usually mean you don't get what you want.