Amarok mobile roadmap

[Keith Rusler]

While I might not be an Amarok developer. I would love to still be able to
sync my database information with the one on my server, since all my
computers sync with it by internet.

If you suggest a design contest, make sure the winner or whatever can
actually stick around and see the design to end.

Last.FM support imho is required :>

The only thing, keep it from being bloated, just easy to use but with some
good functionality like syncing, last.fm, ratings, album art, etc.

On 5 January 2011 12:10, Bart Cerneels <bart.cerneels at kde.org> wrote:

> 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
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20110105/5fd296bb/attachment.htm