Some impressions from aKademy

[Martin Aumueller]

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.


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.


Cooperating with distributors

- Our amarok-release mailing list and the recently introduced practice to 
provide small post-release patches fixing serious issues got an honourable 
mention.
- Often we get bug reports against old versions, which we do not support any 
longer. Instead of only asking to upgrade, it would be helpful to ask people 
to report the bug to their distributors - they might still fix bugs in old 
releases.
- 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.
- 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.


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.


Accessibility

People with viewing disabilities might need special icon themes, e.g. with 
higher contrast. For them, it is very tedious to change icon theming 
individually within each application. Thus, it is important to default to the 
desktop icon theme.

CSS theming is another problem in this regard, as it does not take system 
colours into account in any cases. In KDE 4, colour schemes will provide a 
larger set of colours (e.g. for warning messages, ...) and applications 
should use these colours whenever possible or take recourse to mixing these 
colours if they need more in order not to sacrifice high display contrast. A 
possible solution for CSS themes might be some kind of of pre-processor, 
which applies system colours to CSS.

As much functionality as possible should be available with only a keyboard or 
with only a mouse. Keyboard usability increases with a reasonable tab order.

Making the application usable at small resolutions also helps for having 
reserve space with large font sizes.


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.