Google Summer of Code: Amarok CD Stack Collection View

[Dan Leinir Turthra Jensen]

Monday 24 March 2008 Andreas Schäfer wrote:
> Hello again,
>
> On 11:07 Mon 24 Mar     , Ian Monroe wrote:
> > The current collection browser isn't going anywhere. Amarok 1.4 has
> > always had opengl with its analyzers.
> >
> > Too early to be worrying about such things.
>
> Agreed. I do also think that an OpenGL based implementation can be
> quite efficient.
>
> What would you guys think about the following schedule?
> (dates and lengths again in weeks, relative to SoC begin)
>
> Start-End Length What?
> --------- ------ --------------------
> 0.0-1.0     1.0  Getting to know Amarok's code, build system etc.
> 1.0-3.0     2.0  Basic album listing widget
>                  (ugly looking, but with drag&drop and scolling)
> 3.0-4.5     1.5  Improved font handling & track listing
> 4.5-6.5     1.0  Implement clickable tabs to expand/collapse
>                  parts of the collection (inline tabs, e.g.
>                  one for each artist)
> 6.5-9.0     1.0  Explore different visualization styles
>                  (e.g. flying covers only)
> 6.5-9.0     1.5  Improved visual presentation
>                  (animation, lighting & shading)
> 9.0-end     3.0  Buffer time (improve performance, clean up code,
>                  add configuration options etc.)
>
> As mentioned earlier, I'll be in Kracow from June 22nd till June 26th,
> which will cost me almost one week. Therefore the lengths of the
> packets add up to just eleven weeks, but I'll cover up the lost time
> afterwards.
>
> Mid-term deliverables according to this schedule would be a scrollable
> CD stack widget with drag & drop, not necessarily very nicely
> animated, but with good looking fonts and tabs.
>
> If this schedule and such is alright, I'll file in my submission
> tomorrow. (pretty late 'round here already ^^) Again: any feedback
> highly welcome.
>
> Thanks!
> -Andreas

  i must (as the guy that came up with the idea) note a couple of things of 
course :)

  First of all, your proof of concept does indeed look cool in that good, ol' 
proof-of-concept sort of way, like Nikolaj said :) It'll obviously need to be 
a LOT faster[1], but still :)

  With regards to using OpenGL versus using a QGV, my reason for suggesting 
QGV is that the graphic operations going on are very simple and don't really 
need OpenGL. This argument stems from the fact that Marble isn't OpenGL 
either, and the operations going on there are more hefty than what's 
happening here (sphere rotated in three dimensions, as opposed to boxes 
rotated in three dimensions). And if we can get this thing working on 
lower-end machines by using QGV, well... why not? :)
  Of course, i'm not the one coding it, but those are my reasonings for making 
the suggestion for QGV in the first place :)

  The time-plan looks reasonable - i wouldn't comment on the actual time 
usage, but the schedule itself (as in the order of items) looks good :)

[1] The speed issue is of course the thing with animations longer than roughly 
half a second will make people bored and we really don't want that ;)

-- 
..Dan // Leinir..
http://www.leinir.dk/

                          Co-
                            existence
                          or no
                            existence

                          - Piet Hein