FOSDEM brainstorm

[Maximilian Kossick]

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'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'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'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 "move to Amarok's collection folder" 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'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'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'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  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).


Cheers, Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20070225/9d7f2e1e/attachment.html