mirror of
https://bitbucket.org/smil3y/kde-extraapps.git
synced 2025-02-24 19:02:53 +00:00
27 lines
1.8 KiB
Text
27 lines
1.8 KiB
Text
Collection Architecture
|
|
-----------------------
|
|
|
|
Collection is a container for a set of objects that collectively provider tracks to the application.
|
|
It does this by providing Meta::Base derieved objects via the QueryMaker (which every collection has).
|
|
|
|
On plugin load a CollectionFactory is registered with CollectionManager which listens to the
|
|
newCollection() signal. CollectionManager is responsible for integrating the new Collection within
|
|
the rest of the application. Collection makes user visible strings, icons and other information
|
|
available for the UI to use.
|
|
|
|
TrackProvider actually creates the Meta::Track objects using trackForUrl() which has a specially
|
|
formatted URL that is unique accross application settings. A collection has it's own URL protocol
|
|
which all uidUrl's of the collection's tracks start with.
|
|
|
|
For getting tracks according to metadata or statistical information each Collection has a QueryMaker
|
|
implementation. Any component can get an instance of this specialized QueryMaker using Collection::queryMaker().
|
|
CollectionManager has a special QueryMaker that will return results of all the registered collections
|
|
using their queryMaker(). Use this if you want a track resolved without caring about it's origin.
|
|
|
|
TrackProvider and QueryMakers can be used seperatly from the collections. In practice though you'll
|
|
find only TrackProvider getting used by Services and the filesystem browser. If needing to combinine
|
|
it with a QueryMaker you are probably creating a Collection anyway.
|
|
Also note that Collection objects don't use shared pointers so they are not especially well protected
|
|
against getting removed. Holding the pointer to a QueryMaker for a prolonged amount of time
|
|
invites problems (e.g. when the usb device is removed. We had a number of bugs for this)
|
|
|