GSoC proposal: Enhanced Amarok UI

[Enrico Ros]

Thanks for the feedback Leo, it's really valuable!

On Wednesday 01 April 2009 15:08:09 Leonardo Franchi wrote:
> 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.

Frankly I think this is a high risk/high gain kind of project. Comparing the 
scope of this project with others I see that this is huge.. :-/ I know it will 
take time but I think that it's a kind of "research" that should be done 
before setting the current interface in stone.
  My belief is that a QGraphicsView based MainWindow, using OpenGL if 
available will be faster than the current UI implementation, and it will allow 
for things that are just not possible with this implementation (well, maybe 
they are not needed too, but let's leave some room for improvements ;-)).
  I think I'll shrink the scope. So I'll drop the "reacting to variables" 
stuff, even if a guitar-gui-for-a-rock-track Vs a laser-gui-for-a-trance-track 
may be appealing to someone. So I'll drop that.
  Also you're right on the components and configuration stuff. I won't add any 
option to let the user configure the layout.

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

We could just ship with the kinetic sources (they're not too many files), if 
4.6 won't be widespread by the time my code will (hopefully :-)) be merged.

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

What a pity! I think that analyzers are cool and amarok should have them. 
Anyway it's better to be ready when the spectrum will come ;-) (generating 
some fake input in the meanwhile, for example..).

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

Good to know. I'll take maximum care for not breaking stuff in trunk so. And 
I'll ask for review when modifying existing code.

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

You're right, I'll be more detailed after completely defining the scope.

> > # 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?

I have some bits to do at school until the end of June. About the time.. I 
don't know. It's 8hr/day * 5days/week ok?

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

Thanks a lot for your input,
Enrico

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Gioca con Poker Club! Scegli il torneo che fa per te, ogni settimana puoi vincere oltre 240.000€!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?midˆ02&d=1-4