D10972: [RFC] Exposing slideshow to MPRIS controllers

Sun Mar 11 02:54:21 UTC 2018

kossebau added a comment.

  In D10972#221142 <https://phabricator.kde.org/D10972#221142>, @rkflx wrote:

  > I pondered for quite a bit, and I think mapping slideshows to media players and then assigning buttons is fundamentally flawed.

  You mean "music player" or "movie player", right? Because ",media" by itself is an abstraction, and slides/pictures are a type of media, no? :)

  But let me make clear where I come from to show up with this initial patch:
  over the last years I observed myself and others in quite some situations where it would have improved life style if one was able to remotely control the device which ran a presentation (e.g. giving a talk/lecture while walking across the room/stage, or giving a photo/videosnaps report and resting with your fellows in comfortable furniture).

  Now one could design the perfect suited software/hardware solution for those generalized use-cases. Chance to get it done rather 0 %.
  Or one could see to make reuse of existing infrastructure & tools which are not perfect, but get the job done for a start. And ideally that initial setip advertises that there is a solution to the problem, so more people no longer avoid the problem but enjoy the use-case, and with more users there is more chance of resources to improve things into a perfect solution.

  I totally agree that this patch will not provide the perfect solution. And I also agree the MPRIS spec at v2.0 is not yet the golden one, as initially said the goal is also to collect more experience by using it in the field for slideshows to improve it. And the current implementation of MRPIS-UIs in Plasma are IMHO music-player centric, possibly because that was the only use-case and thus their driver so far. Same with UI in KDE Connect.

  But to restate (because I am tired right now to write things short, pardon me): the idea of this patch is to start off from something that works now with the things that are available. It's enabling new things without waiting for the perfect solution to be done first.. And not blocking the perfect solution, rather providing more feedback by the use of this first prototype.

  > 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).

  Agreed. And it is where I started from :) But missed to point that out and the fact that I already had went shopping for things that can help get a first implementation/solution now and this is what I returned with in my bags. By just writing this patch (well, a variant where CanPause=true and just mapping MPRIS Pause to GwenView's Stop), I could give a trip photo report using Gwenview on the computer and leaning back onto the couch with a mobile and controlling things with legs-up via KDE-Connect (just had to switch to Remote Input when needing to go to previous slide ;) ).

  Your proposals here for the UIs make sense to me, and I will add them as further material for the MPRIS 3.0 collection on the above linked wiki page. Just, next to finding agreement on that new protocol/spec they also need (re)implemantion on the complete chain first.

  > 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.

  The inital patch was done as proof of concept & to inspire possibilities, adapting to the existing behaviour and code of gwenview (which does "reset", not "hold" on the "Stop presentation" action). I did not want to challenge that on first contact with you the maintainers :) Or invest more into the patch first only to find out you do not want this at all.

  My expectations have been you could answer my questions, then I would add the MPRIS adapter code, and then we would together extend things to make the slideshow feature slightly better, also with the new use cases of remote controlling, and iterativly shape things into sanity (too bad no managers around who could be bought into by saying "agile!" ;) ).

  To be frank, the whole interaction pattern around Gwenview's slideshows confuses me. E.g. when entering the slideshow state from a non-fullscreen window, when leaving it (e.g. by ESC key) I end up in fullscreen state still. And I can enter slideshow from normal view, but not full-screen in folder-browse mode. And when in full-screen single-file view mode, the actual "slideshow" being on actually only means automatic advancing to another image/video to show, after timeout/video-done. Where my concept of slideshows before was not involving only automatic advancing, but included any (fullscreen) display of the individual "slide" items also those with manual advancing only. So Gwenview's fullscreen single-file view mode alone already means slideshow to me, as I can give the slideshow by manually walking through the images and videos. "Autoplay" or "AutoProceed" or a more fitting term might be a more matching name for the given UI concept perhaps than "slideshow"?

  Then there is the duplication of the concept "Start" when it comes to a video being the current item. For one videos are autostarted if switched to. But when having paused a video as current item, calling "Start Slideshow" does not unpause the video, other than perhaps expected.

  Also is there no indication of the timeout on a image, so the change to the next image comes a little at a surprise time.

  Next to that, but perhaps independently I also would like a distinction between "Start slideshow from begin" and "Start slideshow, but jump straight to currently selected image". The latter is what happens now, and it is both unexpected most of the time, but also needs additional activity to make sure one really has the first image selected when wanting to show all the files.

  So.... IMHO independent of exposing things to remote via MPRIS, Gwenview things themselves could see some more twisting please :)

  BTW, https://en.wikipedia.org/wiki/Media_controls taught me there even are some ISO/IEC specs for the concepts of Play, Pause, Stop & Co :)

  > 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?

  Sure. Patch update coming in, there now Pause and Stop MPRIS actions both SlideShow::stop. And the MPRIS states "Playing" & "Paused" now correspond to SlideShow->isRunning(), while "Stopped" is when no slideshow is possible (i.e. action is disabled).
  The bends things a little, as the MPRIS spec demands that "Stop()" "Stops playback", so instead going for "Paused" state would be wrong, but we could just claim someone else directly afterwards called "Play()" and then "Pause()",
  From what I tested, Plasma MPRIS controllers (UI and keyboad media key handler) nicely dealt with that.

  Late in the night, but might not get back to computer tomorrow, so to keep things a little rolling this braindump here, hopefully consumable.

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/20180311/ddcc06ec/attachment.html>