GSoC proposal: Enhanced Amarok UI

Thu Apr 2 10:38:59 UTC 2009

On Wednesday 01 April 2009 18:38:46 Enrico Ros wrote:
> 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.

WRT dropping the scope of it, I appreciate the fact that you agree with me, 
but if you do disagree please do argue your opinion! If you think it is 
doable, I'm definitely open to be persuaded :) i'm just trying to make sure 
that it's discussed at least. 

the part that personally i'm least comfortable with is turning the whole 
window into an opengl-accelerated viewport. first of all, i don't even know why 
we want to turn amarok into a pure opengl app, but thats besides the point. 
i've played around with the few opengl plasma applets, and they tend to hog up 
a good % of my CPU (and i have a nvidia 8600gt and intel 2.5ghz cpu)... so it 
would be anything but light. and then, what about users who don't have fancy 
graphics cards or cpus? also, if the whole app is a QGV, we're still obviously 
going to use standard widgets for a lot of it, and so then we enter the 
quagmire of the QGraphicsProxyWidgets, and while they are mostly good as a 
hack, I really can't imagine using them to embed *all* of amarok. they still 
have issues with mouse events, popup widgets, etc.

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

yep this isn't really a problem, just wanted to bring it up.
> > >   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..).

yeah, it is a shame. too bad the proposed student got a better job :P

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

yeah the idea is just to keep students integrated with the community 
throughout the summer, it makes everyone happier that way :)

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

yeah, just wanted to make sure you don't have a full-time job you aren't 
telling us about! (quite a few students don't realize that the SoC is meant to 
be a real job, so they have a lot of things planned at the same time...)

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