Amarok mobile roadmap

[Bart Cerneels]

Hi guys

markey and me are seriously considering working hard on a mobile port
for this: http://qt-apps.org/news/?id=340

I've been investigating how to do such a port for a few months so let
me share my insights.

* The future is Qt Quick:
UI design will be done completely using QML, C++ is only used for the
business logic and to extended QtDeclarative.
Using different QML files (let's assume its possible without a
recompile) we can quickly try out UI experiments and easily create new
specialized interfaces for other platforms.
In the context of the competition and device availability though we'll
start with a handset UI for N900.

* Developers suck at UI design. NO DESIGN BY COMMITTEE!
We've had enough epic discussion threads about tiny design choices
that don't go anywhere. Not to mention the result leaves much to be
desired. So let's leave the design of the UX (User eXperience) to
designers. People with skills, training, experience and interest to do
so.
We currently don't have much design talent in house but those we do
have tend to be to busy to commit. That is why I propose to hold a
design contest once we have some larger parts of Amarok accessible
from QML. We'll select a winner and work with that person to extend
the design to completion. He/she will be our design dictator with
final responsibility over the UX.

That said we do need to prepare the amarok codebase for QML so this
developer will say something about design:
We have 3 major areas in amarok: media, context and playback (controls
and queue). Those 3 will undoubtedly be present in some form in any
UI. So we need to make these accessible. More on that later.

* Dependencies are a porting nightmare:
We need to get rid of some dependencies that will make it very
difficult to compile for other platforms. Specifically mysqle is
troublesome, even on desktop we've noticed. Unfortunately our best
collection and a lot's of services need sqlstorage. Short term I
suggest we bring back sqlite. Long term we need to move away from SQL.
I've already started to do that for the OpmlDirectory [OPML].
Eventually we'll integrate with platform services as much as possible.
QtSparql is a great tool for that [qtsparql] [tracker].

* Modularization:
In order to support multiple platforms with one codebase we need to
take modularization very serious. Jeff has spend some effort, but we
need a lot more work.
Ideally our sourcetree would be grouped by functional dependencies.
ex. SqlCollection + SqlPodcasts + SqlPlaylists in one subdir (==
plugin) which can be include by the top-level CMakeLists.txt.

The roadmap is like follows:

1) modularize
2) "lessql": sqlite or direct to tracker 0.6 (N900, not sparql)
3) proof-of-concept QML UI, example for design contest
4) complete mobile UX targeting N900 and N900+1 with contest winner.

4+) target more platforms, even consider desktop UX with QML and
SparlCollection (nepomuk & tracker with one stone).

[OPML] http://gitweb.kde.org/amarok.git/shortlog/refs/heads/stecchino-IncrementalOpmlDirectory
[qtsparql] http://qt.gitorious.org/qt/qsparql-development
[tracker] http://live.gnome.org/Tracker/Documentation/SparqlFeatures