D10972: [RFC] Exposing slideshow to MPRIS controllers

Mon Mar 12 17:40:55 UTC 2018

kossebau added a comment.

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

  > > make this an optional build feature?
  >
  > Not sure whether Gwenview currently runs on Windows, but it's a nice thought. I'd say handle it just like Elisa does: Make this dependent on whether DBus is available. (A separate feature toggle could always be added later on if people ask for it.)

  Okay, patch updated to that.

  >> make this an optional feature toggable in the settings, where/how best?
  > 
  > We are wary of adding too many config options. Did not check, but if JuK or Elisa don't have that as an extra option, we should also go without one (unless other #gwenview <https://phabricator.kde.org/tag/gwenview/> members think differently!?). We can revisit this decision later, if need be.
  > 
  > However, there is a slight twist which I only discovered recently: The mediacontroller applet is also visible on the lockscreen. For Gwenview's use case that's pretty useless, because the lockscreen simply hides any picture from the user. Moreover, rightfully people will complain we are exposing their photo collections to the public if all they did was running Gwenview in the background.
  > 
  > What do you think about detecting the lockscreen and disabling the feature then (just like KWallet can close itself in that case)? That would be easier than separately signalling something to the controllers. (Maybe there is even already some code handling inhibition related things, you might want to check that.)

  Hm, good question. After some initial thoughts, IMHO having access to the current playlist has a similar risk of privacy leaking (no-one should know I listen to unpopular music XYZ or audio book ABC or watching movies from insane series 123 ;) ). For now I would just opt for: say No to screen locker media controls in general. But no decided opinion yet, as I do not use it. I can see how this being a new feature can be surprising to some, even if consistent.

  >> any idea how to create unique track ids based on the media url?
  > 
  > Would hashing the path work? I'd assume the ID should be unique only per MPRIS "session", i.e. renaming and moving files could result in different IDs.

  When we later want to support MPRIS tracklist/playlist, ideally that mapping can be done in both directions, without overhead. Any hashing would also need bookkeeping for allowing the inverse (and then there is the minimal risk of collisions).
  I guess for now we could simply encode the url/path and use that.

  >> how to provide thumbnails to the mpris controller via temp files whose url then can be passed in the metadata?
  > 
  > If that means that Gwenview should compute a temporary thumbnail and write it to disk multiple times per second in case someone holds done the arrow key in either Browse or View mode, that's a no-go. There are already thumbnails in the standard thumbnails directory which are shared with Dolphin (at least for most part, because there is more in-memory thumbnail handling happening which I haven't looked too deeply into yet, see also discussion in D9078 <https://phabricator.kde.org/D9078>). Controllers should just access that cache, or be told by Gwenview about the actual file location in that cache.

  That's a good idea with the standard thumbnail cache. Just, MPRIS does not specify that the controllers should go for those thumbnails, so to be on the safe side we better point them ourselves directly to a matching thumbnail. Any pointers in the Gwenview code where one could read-out the matching paths to the thumbnail in the cache?
  Though some thumbnailers might only generate thumbnails on the fly (official option, e.g. when there are already thumbnails embedded in the file itself). And in case of unsaved changes (e.g. rotated images) ideally we would still create a matching custom thumbnail ourselves.

  >> Still need to learn how videos are supported (so if with sound), but will add then once I found out. Hints from Gwenview members welcome :)
  > 
  > Yup, playing videos with sounds should work. However, see comment below, full video support via MPRIS is probably material for later.
  > 
  > As for your comments about Gwenview in general: I'm only trying to make sense of it and helping fix things, I'm not the author or anything. Gwenview should be very simple, and IMO at least some of your suggestions clash with that. The fundamental paradigm (which I agree needs more polishing to shine through) is this:
  > 
  > - 2 basic modes: Browse and View, switching between them is done by [Enter] and [⎋] or toolbar buttons. (The Start Page is the odd poster child, but we are thinking about upgrading it, i.e. allowing fullscreen also there.)
  > - Both modes have a windowed and a fullscreen variant, you switch via [F11] or the toolbar button.
  > - Navigation is done by pressing a key or a toolbar button.
  > - The slideshow feature is nothing more than a cute little bot pressing the forward button once in a while for you. It's opt-in and understated. There is a shortcut in the menu which goes to View, switches to Fullscreen and activates the slideshow bot in one go. For consistency reasons [⎋] does not undo that, but activates its default action. Normal users are not expected to use keyboard shortcuts, for them the Leave Fullscreen button will work just fine.

  I see. FTR I would not subscribe to ESC being a key shortcut not for normal users, but your call, I will not be another cook to add more ingredients to the design soup :)

  > As for videos and their relation to pause/forward etc.: Yeah, we know about that one (see endless discussions on Phab and Bugzilla). It's a tricky problem and we'll tackle it eventually, but for now let's not throw the baby out with the bath water. Until the regular video interaction/handling is defined properly, it does not make much sense to look at the MPRIS side.

  Okay.

  >> "Autoplay" or "AutoProceed" or a more fitting term might be a more matching name for the given UI concept perhaps than "slideshow"?
  > 
  > Those are too technical. I tried to find something better, but always ended up with "Slideshow" in the end. Unless someone comes up with a better alternative, that's how it is.

  I saw that "Auto-Advance" seems to be a term that can be found in image/slides related software, perhaps worth a consideration.

  > Hopefully all open questions are answered now, if not let me know.

  Thanks a lot for the quick and detailed reply, got things some way. As by comments above, thumbnails and unique track ids still need more thinking, will play some more with the code tonight.

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/20180312/2a62f8d9/attachment.html>