GSoC proposal: Enhanced Amarok UI

[Enrico Ros]

On Wednesday 01 April 2009 18:14:13 Ian Monroe wrote:
> On Wed, Apr 1, 2009 at 8:08 AM, Leonardo Franchi <lfranchi at kde.org> wrote:
> > 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.
>
> I agree with Leo here. I don't see the appeal of being able to move
> stuff around. This is perhaps something to think about after we're
> happy with how it looks. Developers not being able to make up their
> mind is the worst possible reason to create options. Plus my hatred of
> options is legendary. :)

I think I won't add the code to let the user modify the layout (or add/remove 
things). However, that kind of interaction may be good to, for example, 
dropping a vertical analyzer and the left and another on the right side of the 
window. Let's do like this: if usability-wise this is not a problem, and we 
find a way to add options without adding options (:-)) we will consider the 
user interaction again later on ;-) 

> I can easily see people accidentally dragging stuff. I doubt I'm the
> only one who has had coworkers and family ask for my help when their
> Windows XP start bar somehow ended up in a vertical position

Of course an interaction paradigm like "editing stuff" will have an "editing 
mode" in which you compose the interface like "paper prototyping". I mean: we 
should make clear that now "you're editing the interface". Anyway.. this 
(maybe) will come later, when the picture will be clearer (for me too).

> Having it all painted with OpenGL probably wouldn't work well, due to
> Qt limitations. We've tried to paint like the QGV with OpenGL and it
> didn't work well.

There are many hazards using OpenGL with QGV. I worked on 2 projects like that 
(and they look good) and I'll write a guide about that, one day or the other 
(maybe this SoC will be the perfect reason to do so...).

> > 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.
>
> I don't share this concern, as-stated it seems pretty summer-sized to
> me, especially for someone of Enrico's experience.

Yes yes, as I wrote I share this concern too :D I prefer to narrow the scope a 
bit to ensure that this things I do are correct, fast and don't crash too much 
;-)

> > (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)
>
> I think this is a pretty minor issue. QtKinetic is no Plasma so I
> doubt it will be much of a moving target (and we'd have control over
> when to upgrade anyways). So it shouldn't be much of an issue to
> include it. Porting to cmake will be a hassle, but nothing like
> qscriptgenerator. :)

Good to know! Agreed ;-)

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:
 Cerchi lavoro? Emergi dall'anonimato dei CV scritti, fatti notare: invia il tuo VideoAnnuncio gratuito e scegli un omaggio
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8860&d=2-4