D10972: [RFC] Exposing slideshow to MPRIS controllers

Sat Mar 3 18:11:19 UTC 2018

kossebau added a comment.

  In D10972#217603 <https://phabricator.kde.org/D10972#217603>, @mtijink wrote:

  > In D10972#217592 <https://phabricator.kde.org/D10972#217592>, @kossebau wrote:
  >
  > > This proposal maps a slide to a "track" in MPRIS terms, and the complete slideshow to a tracklist. Given the properties of a track match that of a slide, and the same for a tracklist matching that of a slide set. Edit: Also consider that some slides, as with Gwenview, can be movies (like animated GIFs & Co), so that mapping makes even more sense (to me).
  > >  And MPRIS for the Stop method defines this <https://specifications.freedesktop.org/mpris-spec/latest/Player_Interface.html#Method:Stop> (as you said): "Calling Play after this should cause playback to start again from the beginning of the track. "
  > >
  > > So with that in mind, would you reconsider what you think is logical? :)
  >
  >
  > Ah, with that in mind it makes sense.

  Okay, good getting us to some common grounds.

  > I guess the analogies break down a bit though, since you can't really "play" an image. Would it make sense to use "pause" as "stop" too, if it's not a video?

  Not sure, It might really depend what mental model we will see with users in general: the slideshow being the actual object that is "played" (like you instinctivly saw it) or the individual images/movies, simply organized as playlist/tracklist. Though in the first case users then might expect  Stop to also jump to begin of slideshow.
  Looking at the current menu entry  in Gwenview itself and its behaviour: it just says "Stop slideshow" (so does not use the term "Pause", though uses an icon with Pause symbol, not Stop symbol). By the behaviour it stops the slideshow at the current image and keeps that selected., also resets the display timeout to 0, so on activation of "Start slideshow" again it hehaves as also specified for the MPRIS Stop action.

  But I can see how people might be confused about seeing the "Pause" media key on their keyboard not work, once they can use the media keys due to MPRIS and e.g. the Plasma media controller applet. The difference between Stop and Pause for most users of image slideshows might be rather academical for what I assume the typical use-cases. Possibly the best escape from this challenge is to add an implementation of Pause to Gwenview itself :)
  But IIMHO that is slightly orthogonal to this patch, unless it will conflict with the needs to match the MPRIS spec. And possibly might gain from collecting some usage experience first.

  My developer's brain used to abstracting things :) sees it like this:
  a "track" is a media object which can have multiple parallel subtracks of types like typically sound and image-frames (not wide-spread but possible would be physical object control like for puppets moving, fountains shooting, pipes of street organ blowing, light spots glowing, or, he, odor spraying ;) ).
  And the player then goes and "renders" the data from the tracks. The data themselves would  either allow random access because coming as fixed object from some storage like filesystem or full database or coming from some deterministic data generator. Or the data would not allow random access, because it is generated non-deterministically e.g. from sensors on the physical world (like microphone, camera) without any buffering.

  So with that abstract thinking a simple static slide with some timeout is the same as a short video just showing only the same image. And a simple static slide with no timeout is the same as a video livestream showing only the same image. And thus "Stop" and "Pause" with their different concepts at least by design should be applied the same.

  If we think further in that grand plan as sketched initially, slides in a presentation show also can have a let's-call-it sub-slideshow, where a slide can reach several states by items appearing, changing or disappearing (and just thinking about linear organized shows :) ). Once we get there and try to create model concpets for the needed new MPRIS interfaces, perhaps the right now proposed mapping has to be rethought indeed. But for what I drafted some time ago, mapping for now a single (main) slide, which is usually shown for
  Multi-hierarchy track notation might be also interesting for non-3-minutes-pop-music tracks. Think movies separated in story chapters, classical Western music (operas, synfonies) being composed of units of units. So the same structuring as known e.g. from books might be useful to have, to allow navigation using the same interaction patterns where sane.

  Amd all that while trying to be simple by default, but powerful when needed. Some road ahead. Hopefully not too bumpy or being a dead end :)

REPOSITORY
  R260 Gwenview

REVISION DETAIL
  https://phabricator.kde.org/D10972

To: kossebau, #gwenview
Cc: mtijink, ngraham, nicolasfella, #kde_connect, rkflx, broulik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180303/9d31674d/attachment.html>