GSoC proposal: Enhanced Amarok UI

[Bart Cerneels]

2009/4/1 Enrico Ros <eros.kde at email.it>
>
> Hello Everybody!! Here is my proposal for the Summer of Code.
> Anybody willing to mentor me??
>
> ------  ------  ------  ------
> # Motivation for Proposal / Goal:
>  Improve the look & feel of Amarok User Interface, taking advantage of the
> latest Qt Software technology. Essentially I want to make the UI pluggable in
> a way that each component (the 'player bar', the 'context browser', the
> 'playlist', the 'analyzers', etc.) can be mixed and layouted by the user or
> automatically.
>  In the meanwhile I hope to raise the performance of the UI, accelerate
> graphics where available, and loosen implementation constraints to give
> designers more freedom (see [1]).
>  In the remaining time I'll implement some fancy components for the pure
> pleasure of the eye ;-)
>
> # Implementation Details:
>  The first step will be to abstract the MainWindow class to allow it to be
> reimplemented in other ways. This is important in 2 ways: 1. the ui<-
> >functionality decoupling that is brought in, 2. I'll be allowed to work on
> the “pluggable container ui” side-by-side with the actual MainWindow, that
> will remain the default.
>  Then I'll define what a “Component” is, and the related concepts. Here is are
> some key points:
>  - the user interface may react to some variables (user input, user habits,
> music type, tags, beats, time of the day)
>  - the ui won't get in the way of the user
>  - Amarok must work even with an empty ui
>  - different component aggregations are called “presets” (mini player, compact
> player, [1], are presets)
>  - the current MainWindow look will be the default “preset” of the ui
>  Then the work on the Container will begin. I'll support the layouting logic
> of the components and Drag & Drop component reordering. This is the point
> where Qt Software's Kinetic and StateMachine frameworks will be used. OpenGL
> acceleration will also be used on the container. This will even allow for
> pure-OpenGL components (Amarok's CoverFlow-like component will be resumed at
> this point, and will allow for effects like [2]).
>  Then I'll develop additional components (analyzers mainly, and cpu cycles
> wasting eye candy components). For the analyzers I'll coordinate with the
> students working on the related Phonon SOC project (at this point Amarok's
> interface should already be present), or I'll provide a dummy interface for
> later binding if that project is not on the way.
>  The development will probably be done on a git repository that tracks the
> SVN trunk, to allow for an easy merge of the work, provided that it will prove
> good.
>  In the early design phase I'll try to make sure that the most interesting ui
> ideas by designers, usability experts, users and developers will be doable (I
> already have lots).
>
> # Tentative Timeline:
>  - may: integrate all the feedback from designers, artists, developers and
> create the architecture
>  - june: do the ui decoupling, that allow for different MainWindows to be built
>  - july: implement the “components” ui, with layouting and live editing
>  - august: implement some components for a new, to be decided as we go, design
> (I hope :-)
>
> # About Me:
> I study Electronics Engineering at the Universiy of Padua (Italy). I like open
> source and have been involved in the kde community before (fixing performance,
> working on okular, on the themed kdm and amarok). I'm really passionate about
> graphics, 3D acceleration, HMI and saving cpu cycles for a greener world ;-)
>
> [1] http://www.kde-
> look.org/content/show.php/A+Media+Player+for+KDE4?content=94472
> [2] http://img14.imageshack.us/img14/6241/amarokcoverspq.jpg
> ------  ------  ------  ------
>
> Enrico
>

One of the main beneficial results of this project would be that GUI
components will be better separated and not be interdependent. This
will allow us to experiment more easily with new concepts.
Dynamically changing the UI composition would only be a gadget on the
desktop version, yet small screen devices might benefit immensely. We
could offer the same basic Amarok UI even if it doesn't all fit on the
screen at the same time.

I can fully support this project providing that the improvements to
the code will land in trunk fast and in relative small chucks. So I
propose not to use one big git branch but push to svn as soon as it
compiles and runs.
Try to break down the coding work into chunks as small as possible and
base your timeline on that. In any case you'll need to communicate
very regularly and clearly with the code dev's all the time, which
means: be on IRC 24/7 :)

Bart