Some impressions from aKademy
aumuell at reserv.at
Fri Sep 29 00:49:21 UTC 2006
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.
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
- 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
- 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.
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.
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.
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.
More information about the Amarok