Some impressions from aKademy

[Mark Kretschmann]

On Friday 29 September 2006 02:49, Martin Aumueller wrote:
> At aKademy, we had interesting presentations and discussions. Here is a
> short summary of my impressions related to Amarok. And if you ever have the
> possibility to attend one, then do so - it's always good to get a more
> global view than just circle around a single application.

Thanks for this report, it's very valuable.

> KDE 4
>
> The optimistic estimates seem to agree that KDE 4 will be released in about
> 1 year. Even more time will pass until it hits most people's desktops. What
> does this mean for us? If we start our KDE 4 port now, then we won't be
> able to release a new version for one year. A long time in Amarok's terms.
> Instead of going KDE 4 right now, we could do a lot of refactoring (port to
> another database backend, database scheme reorganization, separating
> internal data represenatation from display in order to prepare for MVC,
> making subsystems more independent, providing for better scriptability and
> more powerful plug-ins...) already in a KDE 3-based version and starting to
> port when a better timeline for a KDE 4 release is available.

Yes, I agree with your position. Starting to port now and then not having an 
Amarok release for a full year wouldn't be good. We would lose direction and 
our users (who are used to our rapid release cycle) would become impatient.

If we are to make a 1.5 release, we could also start to remove all X11 
dependencies, in order to make the final move to KDE4 easier.

> Cooperating with distributors
>
> - Generally, distributors want to ship a consistent system. Thus, they have
> to change the default icon theme to the desktop icon theme. With such a
> setup, casual users will be happy because everything looks similar. More
> interested users will find the configuration option for changing the icon
> them anyway.

This does not change my position regarding our icon theme. I maintain my view 
that it must stay default, otherwise it's next to useless.

Distributors can patch Amarok very easily to change this behavior, if need be. 
So I think they are complaining over a non-issue.

> - An important issue is the mp3 decoder. Real Media allows for 
> using their shared decoder libraries only in Real applications. Thus, SUSE
> can no longer provide mp3 playback support via the helix engine. Getting
> libmad licensed is prohibitively expensive, however providing a
> closed-source mp3 plug-in into xine would be affordable. But this is only
> possible if we provide a GPL exemption for loading proprietary plug-ins.

Well yes, remember that I had raised exactly this issue back at K3M? But 
apparently only SUSE is concerned about this issue, and at K3M the tenor was 
to just not care about it. I guess this needs further discussion.

> Stability
>
> Everybody loves Amarok, because it's a cool program. Everybody would love
> it even more, if it was more reliable. One area full of problems is
> threading. Our fixHyperthreading() is no fix in any case, and it reportedly
> also does an insufficient job as a work-around. For distributors who just
> want to quickly fix a bug w/o digging too deeply into the code, it is often
> unclear which class is supposed to be called from which thread. And in
> special, there are suspicions that our CollectionDB is called w/o proper
> locking.

I agree stability is absolutely crucial. But I have yet to see evidence for 
instabilities with our latest releases. We monitor user feedback constantly, 
through bug reports, IRC, and forums, and I have not seen any alarming 
reports lately. What gives?

(And yes, I realize you've probably been talking to Dirk ;)

> Kexi
>
> I think we should have a close look at using kexidb as our database
> back-end. This would provide access to sqlite, mysql and postgresql
> databases with a unified api. In addition, this should allow users to
> migrate their database from one back-end to another.

Interesting. But is Kexi well maintained, and is it relatively guaranteed that 
this stays so? What if Kexi development comes to a halt after we have 
switched? I'm cautious about introducing any new KDE dependencies.

-- 
Mark