7 | Provides access to a short list of tracks which were recently played or 8 | will be played shortly. This is intended to provide context to the 9 | currently-playing track, rather than giving complete access to the 10 | media player's playlist. 11 |
12 |13 | Example use cases are the list of tracks from the same album as the 14 | currently playing song or the 15 | Rhythmbox play queue. 16 |
17 |18 | Each track in the tracklist has a unique identifier. 19 | The intention is that this uniquely identifies the track within 20 | the scope of the tracklist. In particular, if a media item 21 | (a particular music file, say) occurs twice in the track list, each 22 | occurrence should have a different identifier. If a track is removed 23 | from the middle of the playlist, it should not affect the track ids 24 | of any other tracks in the tracklist. 25 |
26 |27 | As a result, the traditional track identifiers of URLs and position 28 | in the playlist cannot be used. Any scheme which satisfies the 29 | uniqueness requirements is valid, as clients should not make any 30 | assumptions about the value of the track id beyond the fact 31 | that it is a unique identifier. 32 |
33 |34 | Note that the (memory and processing) burden of implementing the 35 | TrackList interface and maintaining unique track ids for the 36 | playlist can be mitigated by only exposing a subset of the playlist when 37 | it is very long (the 20 or so tracks around the currently playing 38 | track, for example). This is a recommended practice as the tracklist 39 | interface is not designed to enable browsing through a large list of tracks, 40 | but rather to provide clients with context about the currently playing track. 41 |
42 |A mapping from metadata attribute names to values.
47 |48 | The mpris:trackid attribute must always be present, and must be 49 | of D-Bus type "o". This contains a D-Bus path that uniquely identifies 50 | the track within the scope of the playlist. There may or may not be 51 | an actual D-Bus object at that path; this specification says nothing 52 | about what interfaces such an object may implement. 53 |
54 |55 | If the length of the track is known, it should be provided in the 56 | metadata property with the "mpris:length" key. The length must be 57 | given in microseconds, and be represented as a signed 64-bit integer. 58 |
59 |60 | If there is an image associated with the track, a URL for it may be 61 | provided using the "mpris:artUrl" key. For other metadata, fields 62 | defined by the 63 | Xesam ontology 64 | should be used, prefixed by "xesam:". See the 65 | metadata page on the freedesktop.org wiki 66 | for a list of common fields. 67 |
68 |69 | Lists of strings should be passed using the array-of-string ("as") 70 | D-Bus type. Dates should be passed as strings using the ISO 8601 71 | extended format (eg: 2007-04-29T14:35:51). If the timezone is 72 | known, RFC 3339's internet profile should be used (eg: 73 | 2007-04-29T14:35:51+02:00). 74 |
75 |79 | The name of the attribute; see the 80 | metadata page 81 | for guidelines on names to use. 82 |
83 |The value of the attribute, in the most appropriate format.
88 |A unique resource identifier.
95 |The list of track ids for which metadata is requested.
102 |Metadata of the set of tracks given as input.
107 |See the type documentation for more details.
108 |Gets all the metadata available for a set of tracks.
112 |113 | Each set of metadata must have a "mpris:trackid" entry at the very least, 114 | which contains a string that uniquely identifies this track within 115 | the scope of the tracklist. 116 |
117 |124 | The uri of the item to add. Its uri scheme should be an element of the 125 | org.mpris.MediaPlayer2.SupportedUriSchemes 126 | property and the mime-type should match one of the elements of the 127 | org.mpris.MediaPlayer2.SupportedMimeTypes 128 |
129 |
134 | The identifier of the track after which
135 | the new item should be inserted. The path
136 |
145 | Whether the newly inserted track should be considered as 146 | the current track. Setting this to true has the same effect as 147 | calling GoTo afterwards. 148 |
149 |Adds a URI in the TrackList.
153 |
154 | If the
158 | Note: Clients should not assume that the track has been added at the 159 | time when this method returns. They should wait for a TrackAdded (or 160 | TrackListReplaced) signal. 161 |
162 |Identifier of the track to be removed.
169 |
170 |
Removes an item from the TrackList.
177 |If the track is not part of this tracklist, this has no effect.
178 |
179 | If the
183 | Note: Clients should not assume that the track has been removed at the 184 | time when this method returns. They should wait for a TrackRemoved (or 185 | TrackListReplaced) signal. 186 |
187 |Identifier of the track to skip to.
194 |
195 |
Skip to the specified TrackId.
202 |If the track is not part of this tracklist, this has no effect.
203 |204 | If this object is not /org/mpris/MediaPlayer2, 205 | the current TrackList's tracks should be replaced with the contents of 206 | this TrackList, and the TrackListReplaced signal should be fired from 207 | /org/mpris/MediaPlayer2. 208 |
209 |216 | An array which contains the identifier of each track 217 | in the tracklist, in order. 218 |
219 |
220 | The
237 | If false, calling
238 |
The new content of the tracklist.
249 |The identifier of the track to be considered as current.
254 |
255 |
259 | This should correspond to the
Indicates that the entire tracklist has been replaced.
267 |268 | It is left up to the implementation to decide when 269 | a change to the track list is invasive enough that 270 | this signal should be emitted instead of a series of 271 | TrackAdded and TrackRemoved signals. 272 |
273 |The metadata of the newly added item.
280 |This must include a mpris:trackid entry.
281 |See the type documentation for more details.
282 |
287 | The identifier of the track after which the new track
288 | was inserted. The path
289 |
Indicates that a track has been added to the track list.
297 |The identifier of the track being removed.
304 |
305 |
Indicates that a track has been removed from the track list.
312 |The id of the track which metadata has changed.
319 |If the track id has changed, this will be the old value.
320 |
321 |
The new track metadata.
329 |330 | This must include a mpris:trackid entry. If the track id has 331 | changed, this will be the new value. 332 |
333 |See the type documentation for more details.
334 |338 | Indicates that the metadata of a track in the tracklist has changed. 339 |
340 |341 | This may indicate that a track has been replaced, in which case the 342 | mpris:trackid metadata entry is different from the TrackId argument. 343 |
344 |9 | Brings the media player's user interface to the front using any 10 | appropriate mechanism available. 11 |
12 |
13 | The media player may be unable to control how its user interface
14 | is displayed, or it may not have a graphical user interface at all.
15 | In this case, the
Causes the media player to stop running.
24 |
25 | The media player may refuse to allow clients to shut it down.
26 | In this case, the
30 | Note: Media players which can be D-Bus activated, or for which there is 31 | no sensibly easy way to terminate a running instance (via the main 32 | interface or a notification area icon for example) should allow clients 33 | to use this method. Otherwise, it should not be needed. 34 |
35 |If the media player does not have a UI, this should be implemented.
36 |
42 | If false, calling
43 |
Whether the media player is occupying the fullscreen.
57 |58 | This is typically used for videos. A value of true 59 | indicates that the media player is taking up the full screen. 60 |
61 |62 | Media centre software may well have this value fixed to true 63 |
64 |
65 | If
71 | If
79 | This allows remote control interfaces, such as LIRC or mobile devices like 80 | phones, to control whether a video is shown in fullscreen. 81 |
82 |
91 | If false, attempting to set
92 |
99 | Note that the media player may be unable to fulfil the request. 100 | In this case, the value will not change. If the media player knows in 101 | advance that it will not be able to fulfil the request, however, this 102 | property should be false. 103 |
104 |106 | This allows clients to choose whether to display controls for entering 107 | or exiting fullscreen mode. 108 |
109 |
116 | If false, calling
117 |
129 | Indicates whether the /org/mpris/MediaPlayer2 130 | object implements the org.mpris.MediaPlayer2.TrackList 131 | interface. 132 |
133 |A friendly name to identify the media player to users.
139 |This should usually match the name found in .desktop files
140 |(eg: "VLC media player").
141 |The basename of an installed .desktop file which complies with the Desktop entry specification, 148 | with the ".desktop" extension stripped.
149 |150 | Example: The desktop entry file is "/usr/share/applications/vlc.desktop", 151 | and this property contains "vlc" 152 |
153 |159 | The URI schemes supported by the media player. 160 |
161 |162 | This can be viewed as protocols supported by the player in almost 163 | all cases. Almost every media player will include support for the 164 | "file" scheme. Other common schemes are "http" and "rtsp". 165 |
166 |167 | Note that URI schemes should be lower-case. 168 |
169 |171 | This is important for clients to know when using the editing 172 | capabilities of the Playlist interface, for example. 173 |
174 |181 | The mime-types supported by the media player. 182 |
183 |184 | Mime-types should be in the standard format (eg: audio/mpeg or 185 | application/ogg). 186 |
187 |189 | This is important for clients to know when using the editing 190 | capabilities of the Playlist interface, for example. 191 |
192 |