Hi. Bart, Martin, Sven and I had a quite interesting discussion about Amarok 2 yesterday evening at FOSDEM and later at dinner. We made a few notes, and I&#39;m trying to get the results of our discussion into this e-mail as completely as possible.

ContextBrowser Bart is very impressed by the possibilities of QGraphicsView. He proposed implementing the ContextBrowser with QGraphicsView/QGraphicsScene and Qt Stylesheets in Amarok 2. Additionally, we talked about renaming it to ContextView to emphasise that it is a central part of Amarok, and not just another browser. The content of the ContextBrowser should be generated by scripts, using Kross or the Qt4&#39;s QtScript if feasible.

And themes are responsible for displaying that data. Separating the data from the view. An open problem is specifying the format of the data to be provided by the scripts. Browsers We talked about removing the filebrowser and replacing it by a better konqueror context menu. I don&#39;t think the file browser is very useful, except for moving new songs to the collection. If we make it possible to access an option like &quot;move to Amarok&#39;s collection folder&quot; in the context menu of a folder/file, we could remove the filebrowser. A problem might be the support for alternative filemanagers (dolphin, nautilus, ...).

Core components of Amarok shouldn&#39;t depend on browsers. Martin mentioned an example where CollectionDB depended on MediaBrowser, which made the collectionscanner depend on MediaBrowser too. The MediaBrowser obviously doesn&#39;t exist in the collectionscanner, and so it crashed. It should be completely sufficient to load all browsers as plugins. The Sidebar takes care of showing/hiding/positioning them, and the browsers are free to do whatever they want. This would force us to restrict dependencies between parts of Amarok, which is generally a good idea in our opinion to provide easier maintainability and extensibility.

Multiple collections On Saturday evening we talked about refactoring Amarok&#39;s collection. We agreed that Amarok 2 should be able to handle different types of collections (like our current local collection, a DAAP share, a connected media device). The idea is that Amarok key features like Smart and Dynamic Playlists should be able to select songs from connected Ipods or other media devices or songs from remote collections like DAAP or Ampache. One of the consequences would be that queries would be asynchronous instead of synchronous like they are now, but we could add a class which acts as compatibility layer.

MetaBundle We also were discussing the MetaBundle class. We propose to split it into several classes like a TrackBundle, AlbumBundle, ArtistBundle, ... and the TrackBundle should refer&nbsp; to an AlbumBundle and an ArtistBundle. There should be specialised methods in the CollectionDB (or its replacement) returning objects of these classes instead of QStringLists. As an added benefit, this would render AtomicString unnessecary.

Changes to the Database Scheme We estimate sql JOINs based on an integer comparison to be much faster than those based on string comparison. Thus, a persistent url table containing a unique integer id for each track,  its url (not only path, for being able to store references to remote items) and AFT uid should be created. This integer id should replace the url in all places where we use it now.

Album ids should be a unique identifier for an album, not for an album title (e.g. in order to distinguish Greatest Hits compilations by different artists) and the table should augmented with an artist id (the album artist).

<br><br><br>

Cheers, Max<br>