GSoC proposal: Enhanced Amarok UI

[Leonardo Franchi]

On Wednesday 01 April 2009 05:33:31 Enrico Ros wrote:
> Hello Everybody!! Here is my proposal for the Summer of Code.
> Anybody willing to mentor me??
>

Hi Enrico! thanks for submitting a draft. following are some comments.


> ------  ------  ------  ------
> # 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]).

i'll be honest, two concerns come to mind:

1) this is a radical change, and i'm not sure I agree with what i think it is 
you're advocating. turn Amarok into a canvas on which you can arrange any 
number of separate components sounds nifty, but i'm not sure how usable in 
practice. we're not trying to become another foobar2000, with an infinitely 
configurable and endlessly confusing interface :D in any case, I think 
something this different needs some significant discussion.
2) i am a bit doubtful of the project due to the amount of work it entails. 
ust the componentry part (including acceleration, qtkinetic/statemachine stuff) 
plus the "reacting to variables" is a lot of work.

(btw, as qtkinetic will be part of qt4.6 and a solution until then, we also 
need to think about if we want to depend on a qtsolution)

>   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.

just to be clear, the phonon SoC idea is not guaranteed to actually be 
accepted (and we don't even have a proposal for it yet, so there isn't 
anything that *can* be accepted :) we would really like to have it happen, but 
we'll see. 

>   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.

most amarok devs already use git-svn for their development work. also, we 
prefer to have people develop directly in trunk so as to expose the changes to 
the wider development community. if all the development happens in a separate 
branch there is less testing and review, and can lead to more issues when the 
time comes to merge (not code issues, functionality issues)

>   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 :-)

it would be great if you could provide a bit more of a detailed timeline :) if 
you can break down the summer into one- or two- week chunks it'll help in 
defining concrete goals. 

> # 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 ;-)

do you have any other summer commitments? how much time do you think  you'll 
be able to spend on Amarok for the duration of the program?

thanks for the proposal---please don't let me scare you off! i'm excited that 
someone wants to work on the amarok UI as we all agree it could use some love. 

leo

 
-----
lfranchi at kde.org		Tufts  University 2010
leonardo.franchi at tufts.edu                The KDE Project