<table><tr><td style="">rkflx added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D10972">View Revision</a></tr></table><br /><div><div><p>Played around a bit with Gwenview, JuK, Elisa, Amarok and VLC. I could not find <em>any</em> 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).</p>
<p>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:</p>
<div class="remarkup-table-wrap"><table style="border-collapse: separate;
border-spacing: 1px;
background: #d3d3d3;
margin: 12px 0;">
<tr><th style="background: #ffffff;
padding: 3px 6px;"># of Buttons</th><th style="background: #ffffff;
padding: 3px 6px;">Controller UI</th><th style="background: #ffffff;
padding: 3px 6px;">Gwenview</th><th style="background: #ffffff;
padding: 3px 6px;">Impress</th><th style="background: #ffffff;
padding: 3px 6px;">JuK</th><th style="background: #ffffff;
padding: 3px 6px;">Live video stream</th></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">1</td><td style="background: #ffffff;
padding: 3px 6px;">Basic (1 primary button)</td><td style="background: #ffffff;
padding: 3px 6px;">Hold/Resume slideshow</td><td style="background: #ffffff;
padding: 3px 6px;">Hold/Resume slideshow</td><td style="background: #ffffff;
padding: 3px 6px;">Hold/Resume playback</td><td style="background: #ffffff;
padding: 3px 6px;">Start/Stop stream</td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">3</td><td style="background: #ffffff;
padding: 3px 6px;">Simple (+2 navigational buttons)</td><td style="background: #ffffff;
padding: 3px 6px;">+previous/next image</td><td style="background: #ffffff;
padding: 3px 6px;">+previous/next slide</td><td style="background: #ffffff;
padding: 3px 6px;">+previous/next track</td><td style="background: #ffffff;
padding: 3px 6px;">+switch channels</td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">5+x</td><td style="background: #ffffff;
padding: 3px 6px;">Advanced (+more regular and navigational buttons)</td><td style="background: #ffffff;
padding: 3px 6px;">+start/resume videos in slideshow, skip in videos</td><td style="background: #ffffff;
padding: 3px 6px;">+blank screen, advance on bullet level</td><td style="background: #ffffff;
padding: 3px 6px;">+stop playlist, seek through track</td><td style="background: #ffffff;
padding: 3px 6px;">+mute audio, switch filters</td></tr>
<tr><td style="background: #ffffff;
padding: 3px 6px;">4 / default case</td><td style="background: #ffffff;
padding: 3px 6px;">Keyboard (prev, next, stop, play/pause)</td><td style="background: #ffffff;
padding: 3px 6px;">"simple" + x</td><td style="background: #ffffff;
padding: 3px 6px;">"simple" + x</td><td style="background: #ffffff;
padding: 3px 6px;">"simple" + x</td><td style="background: #ffffff;
padding: 3px 6px;">"simple" + x</td></tr>
<tr></tr>
</table></div>
<p>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 <a href="https://kver.wordpress.com/tag/dwd/" class="remarkup-link" target="_blank" rel="noreferrer">DWD</a>, but much more restricted to a specific type of usage and thus implementable.</p>
<p>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.</p>
<hr class="remarkup-hr" />
<p>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 <em>right now</em> in reaction to this button. Of course this can be refined later on when better ways to express functionality become available.</p>
<p>Please tell me where I'm wrong in my thinking, and I'll admit defeat in my mission to keep Gwenview's quality up ;)</p>
<p>Once we cleared up the behavioural part, it will be much easier to take a decision on some of your questions.</p>
<hr class="remarkup-hr" />
<p>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?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R260 Gwenview</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D10972">https://phabricator.kde.org/D10972</a></div></div><br /><div><strong>To: </strong>kossebau, Gwenview<br /><strong>Cc: </strong>mtijink, ngraham, nicolasfella, KDE Connect, rkflx, broulik<br /></div>