GSoC proposal: Enhanced Amarok UI

Thu Apr 2 13:49:14 UTC 2009

On Thursday 02 April 2009 12:38:59 Leonardo Franchi wrote:
> 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.

I really agree. After looking to some other projects I think that I have lots 
of ideas in mind, but I have to be realistic about what I can acheive in a 
limited time frame. I think it's better if I do one thing good versus trying 
to push to many features. I was easy to persuade ;-)

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

Here I must ask you to trust the research nature of this proposal. Of course 
it can end in bad, unaccepted code, but I already worked on projects where the 
OpenGL viewport really made the difference (like interacting with 9 video 
streams in an opengl viewport at 50fps with less than 60% single cpu load).
OpenGL is good for: 
 - fast blitting
 - texture scaling
The Qt OpenGL painter is good for some things, bad for others, and it's still 
improving. Trying to minimize the "bad" (like 'circles' or 'paths') will allow 
to acheive a good performace. If you played with the OpenGL plasma applet.. 
well, that renders with OpenGL to a video buffer, then unpacks the buffer to the 
system memory where the software QPainter used by plasma will blend (!) the 
rendered texture in the plasma canvas... the result: blending the whole area 
at $FPS. Will be slow even if *nothing* changes in the actual applet contents.
By the way, OpenGL support will be off by default. I still prefer software 
rendering (unless OpenGL halves the cpu usage).

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

This summer the closest thing to a job is my girlfriend ;-) It's a pity that 
universities in italy officially stop at the end of june and start back in the 
end of september.. a little misaligned with the summer of code but I'll try to 
compensate that.

Thanks for caring,
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:
 Diventa uno dei magnifici 8! Entra a fare parte della squadra Italiana di Poker Sportivo con PokerClub
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8803&d=2-4