Amarok/Development/Architecture/Previous

From KDE Community Wiki
Revision as of 17:11, 14 January 2013 by Mamarok (talk | contribs) (Mamarok moved page Amarok/Development/Architecture to Amarok/Development/Architecture/Previous: make space for new page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This introduction to the architecture of Amarok 2 is designed to help new contributors understand the different components of Amarok 2 and their interactions. This is a work in progress, and by no means complete. For further and more complete information regarding the architecture of Amarok 2, see also the documentation generated by Doxygen.


Meta classes

The meta classes represent music metadata in an object-oriented manner. All meta classes are abstract base classes. Other components must therefore provide the actual implementations, which are free to retrieve the music metadata in any way. The following meta classes exist:

  • Track
  • Artist
  • Album
  • Genre
  • Composer
  • Year

In addition, all meta classes inherit from a common base class, MetaBase. The base class provides methods to retrieve a textual representation of the actual object (e.g. the artist's name in case of an Artist object), makes all Meta classes observable, and allows access to potentially available special capabilities of the Meta object.

The Meta classes are at the very core of Amarok 2 (replacing MetaBundle from Amarok 1). Every component makes use of these classes, either by providing actual implementations or by using them to access the music's metadata.

Collection

This section covers collections, querymakers, and CollectionManager.

Amarok 2 introduces the idea of Collections. A Collection is an abstract base class, and represents a conceptual storage location of music. Collections are designed to support read/write operations, if these are supported by the actual implementation.

QueryMaker is a mechanism for Amarok to access the music in a Collection. QueryMaker is an abstract base class too, and all Collection implementations must provide a QueryMaker implementation too. QueryMaker usually returns Meta objects. The type of meta object that will be returned can be set by calling one of the startXXXQuery() methods (Please note that startCustomQuery() is not actually implemented anywhere yet). QueryMaker is asynchronous. After configuring QueryMaker, the query can be started by calling run(). As soon as the results are ready, QueryMaker will emit one of the newResultReady signals, depending on the type of the query. Please note that the signal can be emitted multiple times. At last, QueryMaker will emit the queryDone signal. It is safe to delete the QueryMaker object then.

Note: QueryMaker will only emit newResultReady multiple times if MetaQueryMaker is used. MetaQueryMaker is a special QueryMaker that wraps multiple QueryMakers. Although MetaQueryMaker will usually emit the same signal multiple times, it can be made to emit different signals. See TagDialog.cpp for an example. Only use this if you know what you are doing!

Note: Sometimes the asynchronous behaviour of QueryMaker is a hindrance. BlockingQueryMaker will block until the actual QueryMaker object emits queryDone().

EngineController

EngineController encapsulates the Phonon API.

Playlist

Explanation of the playlist, TrackNavigators

ContextView

Service Framework

CollectionBrowser