Center View and Music store integration

[Maximilian Kossick]

On Thursday 01 March 2007, Dan Meltzer wrote:
> On 2/28/07, Bart Cerneels <bart.cerneels at gmail.com> wrote:
> > Hi all,
> >
> > This is related to the results of the FOSDEM brainstorm session, mainly
> > the Context View idea, which I'm re-branding the Center Pane.
> >
> > Now that the context browser is in the center and always visible it might
> > be a opportunity to rethink it's concept.
> > This is related to music stores because I don't think the current tree
> > view browser will scale when music stores get a bigger catalog. Consider
> > a music store that has a web-like interface, it's easier to browse, looks
> > better, albumart, browsing through a catalog based on related artists,
> > genres, recommendations, etc.
> > To implement a store like that we need screen real estate. The only place
> > I can think of that we have that is in the center pane.
>
> I have to disagree with this as well.
> Amarok has always had a three step approach to dealing with music:
> 1)User finds music in browsers
> 2)User appends music to playlist
> 3)User views information about music in context
>
> The ui changes were made to facilitate this.  The context is Amarok's
> greatest feature, we don't want the center tab flooded with all sorts
> of ancilliary information.  Videos and visualizations are both a form
> of context, music stores are not.

If the music store consists of a simple tree view, like magnatune at the 
moment, i agree. But there is no reason that another (prettier) shop 
implementation won't be able to show context to songs which you preview. We 
simply don't know yet.
Which brings me back to the discussion about using plugins for the context 
view (or center view, if that's what it's called now). We don't know what 
kind of implementations are possible in the future (imagine a totally awesome 
pure OpenGL implementation), and we shouldn't give away OUR flexibility to 
change the center view by hardcoding it now. There's simply no reason that 
the rest of amarok has to know how the center view is implemented (granted, 
adding video output to it will take some thought, but it's possible). I agree 
with markey that we shouldn't support 3rd party binary plugins (but we can't 
really prevent them in the end either, but we can make it harder by breaking 
binary compatibility on purpose), but we should make use of them where it 
makes sense for us. loose coupling is just good engineering practice.

> We also have the whole idea of one way to find music.  Collection,
> media devices, and the music stores right now all have a similar
> layout.  I agree that a 10,000 node tree could be problematic--perhaps
> we shoould brainstorm various ways to organize a musicstore at a top
> level besides artist?  Genre is one.. what other ways would you search
> for music if you wanted to find a new artist?

That's not quite true, you can browse artists and thereby discover new songs 
in the context browser.

> Furthermore, putting the music store in the context browser would
> basically be just adding another khtmlpart tab to the browser, and
> letting the user browse their site.  Thats not really integration,
> thats more of a built in browser (hello songbird).

Songbird simply sucks;) And you can do more with a khtmlpart than just showing 
the shop's website, just look at our current context browser. We are free to 
decide not to include a shop plugin when it simply shows the website. 
Everybody who wants to write a plugin in c++ and include it in amarok should 
talk to us before he starts writing it.

> > Now what is interesting is that, when implemented right, context and
> > music stores are just themes for the Center Pane. A reminder: Themes
> > control Widget that display data supplied by Scripts.
> > The things we can show in the center pane are only limited by the
> > complexity of the widget it uses.
> >
> > To tiered to explain more now, will mail the list again tomorrow.
> >
> > Greets
> > Stecchino

Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070301/f1b06bd0/attachment.pgp