D10972: [RFC] Exposing slideshow to MPRIS controllers

[Henrik Fehlauer]

rkflx added a comment.


  Played around a bit with Gwenview, JuK, Elisa, Amarok and VLC. I could not find //any// app which worked flawlessly in Plasma. IMO shipping MPRIS support in a half-broken state does not align all that well with Gwenview's vision of polish (from a user's point of view when they hit "Pause" on their keyboard and in the mediacontroller applet – I do recognize it's important to follow a spec in the longer term, though).
  
  I pondered for quite a bit, and I think mapping slideshows to media players and then assigning buttons is fundamentally flawed. The long discussion above is an indicator for this. We should think in terms of use cases and UI, not in terms of conforming to a spec (which is important, but an implementation detail in the end). In case there is only space for a single button, the question to ask is "What is the most important function which should be controlled by this button?". Stating "Let's disable the button too, because the app does not claim support for one particular function!" should be avoided. Brainstorming:
  
  | # of Buttons      | Controller UI                                     | Gwenview                                          | Impress                                | JuK                                | Live video stream           |
  | ----------------- | ------------------------------------------------- | ------------------------------------------------- | -------------------------------------- | ---------------------------------- | --------------------------- |
  | 1                 | Basic (1 primary button)                          | Hold/Resume slideshow                             | Hold/Resume slideshow                  | Hold/Resume playback               | Start/Stop stream           |
  | 3                 | Simple (+2 navigational buttons)                  | +previous/next image                              | +previous/next slide                   | +previous/next track               | +switch channels            |
  | 5+x               | Advanced (+more regular and navigational buttons) | +start/resume videos in slideshow, skip in videos | +blank screen, advance on bullet level | +stop playlist, seek through track | +mute audio, switch filters |
  | 4  / default case | Keyboard (prev, next, stop, play/pause)           | "simple" + x                                      | "simple" + x                           | "simple" + x                       | "simple" + x                |
  |
  
  This way we avoid any awkward mapping to concepts like "canPause", every app can decide on their own what navigation means and what primary/secondary etc. buttons should do. Think DWD <https://kver.wordpress.com/tag/dwd/>, but much more restricted to a specific type of usage and thus implementable.
  
  Obviously, for this to work the app would have to provide icon and text for the controller to put on the requested type of button and in the context menu, perhaps with falling back to the selection of icons/texts we currently have. After all, in Impress you do not "Play" a presentation, but you "Present" a slideshow. This kind of polish is important, but not really achievable with the current spec.
  
  ---
  
  Now, what to do with your patch for Gwenview? Obviously the current generation of controllers often only has a pause button, and keyboards have a permanent pause button. As "holding" the slideshow is the primary use case, that's what Gwenview should do //right now// in reaction to this button. Of course this can be refined later on when better ways to express functionality become available.
  
  Please tell me where I'm wrong in my thinking, and I'll admit defeat in my mission to keep Gwenview's quality up ;)
  
  Once we cleared up the behavioural part, it will be much easier to take a decision on some of your questions.
  
  ---
  
  TL;DR: In general mapping images to tracks seems sane, but could you make it so that "Pause" as well as "Stop" in the controller or on the keyboard both map to the single corresponding "hold" action in Gwenview for the time being?

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/20180307/2b54f018/attachment.html>