This in the lines of Bug 8670. Please introduce MPlayer-style shortcut keys in Parole. Currently Parole comes with at least several one-key controls similar to MPlayer: f - Toggle fullscreen p / SPACE - Pause s - Stop '+' and '–' - Decrease/increase volume left and right - Seek backward/forward by (?) 2 sec pgup and pgdn - Seek forward/backward 10 minutes. I would suggest a scheme more compatible with what MPlayer ships. Perhaps implementing all MPlayer controls is not necessary/feasible, but only a subset would be very useful. Namely: 9 and 0 - Decrease/increase volume. (Even if it is redundant wrt to '+' and '–', it is still useful since pressing 9 and 0 requires no shift, while + does require a shift. Alternatively use '=' instead of '+'.) m - Mute sound. q / ESC - Stop playing and _don't_ quit. (See Bug 8670. Basically this could be made to have the same effect that currently 's' has: Stop the movie stream instead of actually quitting the player. Personally I see no problems with having three different controls bound to the same action, since to stop a player I always try first 'esc', then 'q'.) left and right - Seek backward/forward 10 seconds. (The current left/right config is very unusable as far as I'm concerned. I very often use 'back 10sec' in MPlayer when I couldn't understand some dialogue/scene and want a replay. Now this is very difficult to impossible in Parole.) up and down - Seek forward/backward 1 minute. WRT to the current setup, my biggest issue is with scrolling Moreover, maybe implement an option to disable one-key controls (other than Space). This way people can have a "genuine" UI in Parole.
First off, about the volume-shortcuts: with editable menu-accelerators enabled you can quickly re-set those (+/-/mute) to whatever you prefer. I don't see a good-enough reason to hardcode that. (Even though mplayer might be popular, it's not the only much-used player out there.) Esc doesn't quit the player atm, it only exits fullscreen-mode. And personally, that's where I see the conflict. In my opinion, it's better used there. With respect to seeking: could be improved. Currently pageup/pagedown goes 10min forward/backward, which can also come in handy. An option to disable those one-key controls (especially as I'm not planning to add as many as mplayer) seems overkill to me.
I've thought about the keyboard shortcuts briefly, and made the following changes: "0" now toggles mute. "minus" (standard keyboard) and "-" (keypad) now toggle volume down. "equals" (unshifted, standard keyboard), "plus" (shifted, standard keyboard), and "+" (keypad) now toggle volume up. I'm not certain about other keyboard configurations, but on the US keyboard configuration, 0, -, and =/+ are directly next to one another, and as far as configuring volume, this is a handy layout. The left and right keys seek by 5% of the total duration of the video. This is helpful for manipulating the progress GtkRange, though it could be argued that this should offer finer control, so perhaps a defined (small) value would be ideal? I'm open for discussion on this. "q" makes little sense as a shortcut, it implies "quit" and not stop. Finally, Parole is a media player, so a "genuine UI" is not really acceptable here. A genuine media player has three basic functions: open, start playback, and configure playback. So one key controls are quite helpful, I would think, for most people.
The 0, -, and =/+ layout seems very nice for adjusting volume. While 'q' is indeed debatable, 'ESC' is already used for a somewhat different functionality (exiting fullscreen). Personally I still see sense in using 'esc' to exit fullscreen, and to stop the stream when not in fullscreen. As far as I go the 'left and right keys seek by 5%' is of little practical interest as different streams are of different lengths and it would be difficult for the user to precisely estimate the effect of this action on any given stream. When watching a media file one would (presumably) want one of the following: - quick backward/forward seeking (say, when you didn't really catch a scene or couldn't understand immediately what a character was saying); for this a left/right -/+ 10 seconds seems ideal. - medium backward/forward seeking (say, when you want to advance 5-6 minutes into a media stream); for this a down/up -/+ 1 minute seems ideal. - long backward/forward seeking (say, when you want to advance to the middle of a movie); for this a pagedown/pageup -/+ 10 minutes seems ideal. (Already implemented.) Of course here I make the case for MPlayer-like seeking defaults, but they seem to me like no nonsense defaults. In my experience this gives the fine-grained control that covers most of a user's seeking needs. I really don't know why I went for the "genuine UI" remark there.
I've implemented the seek-options like this now: left/right: +/- 10sec up/down: +/- 60sec page_up/page_down: +/- 600sec up/down is currently commented, because there's a conflict with another keyboard-shortcut: at the moment those keys are bound to directly jump around in the playlist. this only works when the playlist is visible (at the moment, these buttons don't show the playlist, only give it focus when it's already there). so we have to decide where to use the arrow buttons and whether we want/need the playlist-shortcut.
We finally reached an agreement on the shortcuts-conflict of the Up/Down keys: they will remain as controls for the playlist. I just pushed "Ctrl+Left/Right" as shortcuts to skip ahead/back 1min. As far as I can see this bug has therefore been resolved, or did I overlook any open issues?
(In reply to comment #5) > We finally reached an agreement on the shortcuts-conflict of the Up/Down > keys: they will remain as controls for the playlist. I just pushed > "Ctrl+Left/Right" as shortcuts to skip ahead/back 1min. > Hmm, "Ctrl+up/down" (typo above?) can be confusing compared to 'left/right' or 'pgup/pgdown', and I can see users complaining about this as a bug. But I guess people can get used to "Ctrl+up/down" once the find out about the shortcut. Would it be possible, say, to have 'up/down' scroll the video when the video is focused? And move up/down the list when the playlist is focused? This could be confusing in its own right, but mayhaps better. > As far as I can see this bug has therefore been resolved, or did I overlook > any open issues? > As far as I go it has been. Thanks!
(In reply to comment #6) > Hmm, "Ctrl+up/down" (typo above?) can be confusing compared to 'left/right' > or 'pgup/pgdown', and I can see users complaining about this as a bug. But I > guess people can get used to "Ctrl+up/down" once the find out about the > shortcut. No, not a typo (feel free to check git ;)). The idea is to use the left/right arrow keys for skipping ahead/back, with modifier it's 1min instead of 10secs. Ctrl+Up/Down seems quite inintuitive (and frankly confusing) to me if Up/Down controls the playlist. > Would it be possible, say, to have 'up/down' scroll the video when the video > is focused? And move up/down the list when the playlist is focused? This > could be confusing in its own right, but mayhaps better. We'll actually autofocus the playlist once you hit up/down (meaning: we'll also automatically show it, even if it was hidden, when you hit the shortcut). That solution would be somewhat inconsistent and – again – imo confusing for users. > As far as I go it has been. Thanks! Good to know! :)
(In reply to comment #7) > No, not a typo (feel free to check git ;)). The idea is to use the > I'm waiting for a new release to update my Ubuntu PPA and check out the changes. [1] [1] https://launchpad.net/~landronimirc/+archive/xfce > left/right arrow keys for skipping ahead/back, with modifier it's 1min > instead of 10secs. Ctrl+Up/Down seems quite inintuitive (and frankly > confusing) to me if Up/Down controls the playlist. > Oh, OK. This makes much more sense. > > Would it be possible, say, to have 'up/down' scroll the video when the video > > is focused? And move up/down the list when the playlist is focused? This > > could be confusing in its own right, but mayhaps better. > > We'll actually autofocus the playlist once you hit up/down (meaning: we'll > also automatically show it, even if it was hidden, when you hit the > shortcut). > That solution would be somewhat inconsistent and – again – imo confusing for > users. > Yeah, definitely. The above seems consistent.
Nice, marking it as fixed then.
I've just given 0.4.0 a test ride and here are a few comments: - The "We'll actually autofocus the playlist once you hit up/down (meaning: we'll also automatically show it, even if it was hidden, when you hit the shortcut)." feature is strange and should be removed. To see what I mean: play a movie, switch to fullscreen, hit 'down' and then 'space'. You should see that the stream gets restarted, and there is no obvious way to hide the playlist. I would suggest that there be no 'autofocus playlist' when hitting 'down/up' while the stream is focused. - This is minor: When hitting 'right' the stream scrolls by 10sec, but the visual indication features a noticeable lag (one or two seconds). In Gnome MPlayer this is much snappier. For fun, try to click 'right' quickly several times: the visual lag should be even more noticeable.
One more: - To my surprise the 'mute' functionality isn't a 'toggle mute'. I would have expected that clicking '0' twice would mute/unmute the audio.
Thanks for your comments and for testing 0.4.0! > - The "We'll actually autofocus the playlist once you hit up/down (meaning: > we'll also automatically show it, even if it was hidden, when you hit the > shortcut)." feature is strange and should be removed. To see what I mean: > play a movie, switch to fullscreen, hit 'down' and then 'space'. You should > see that the stream gets restarted, and there is no obvious way to hide the > playlist. I would suggest that there be no 'autofocus playlist' when hitting > 'down/up' while the stream is focused. Not really sure yet what we'll do there. I agree that it's a bit cumbersome and it probably needs tackling, we'll discuss it. > - This is minor: When hitting 'right' the stream scrolls by 10sec, but the > visual indication features a noticeable lag (one or two seconds). In Gnome > MPlayer this is much snappier. For fun, try to click 'right' quickly several > times: the visual lag should be even more noticeable. We're aware of this and in fact it was the same in the 0.3 release/s. Having said that, it's not very high priority at the moment. > One more: > - To my surprise the 'mute' functionality isn't a 'toggle mute'. I would have > expected that clicking '0' twice would mute/unmute the audio. Humm, yeah, that should also be fixed. (Btw, I'm not very happy with this bugreport becoming a mishmash of different things, if you wouldn't mind copypasting this to a new bugreport, that'd be great!)
(In reply to comment #12) > (Btw, I'm not very happy with this > bugreport becoming a mishmash of different things, if you wouldn't mind > copypasting this to a new bugreport, that'd be great!) > Yes, that is suboptimal. I moved all three issues to separate reports.
> We finally reached an agreement on the shortcuts-conflict of the Up/Down keys: they will remain as controls for the playlist. I just pushed "Ctrl+Left/Right" as shortcuts to skip ahead/back 1min. > Now that Bug 9762 is fixed and that 'up/down' will not do anything if the playlist is hidden, I would like to revisit this argument. Currently we have 'ctrl + left/right' to seek -/+1min. While intuitive, it is a bit awkward to access. Are there still objections to using 'down/up' instead? This would be compatible with MPlayer (Gnome MPlayer, etc.) and not necessarily be counterintuitive wrt to the playlist.
Humm, we discussed that as well, but wouldn't it be counter-intuitive if the same shortcut produces different results based on whether the playlist is visible? I think that's something that's a bit too hard to guess for the average user... I personally second the up/down shortcut, but for now we've settled on a compromise.
(In reply to comment #15) > Humm, we discussed that as well, but wouldn't it be counter-intuitive if the > same shortcut produces different results based on whether the playlist is > visible? > Not necessarily: In Gnome MPlayer they adopted an interesting solution. When the playlist becomes visible, none of the left/right up/down pgup/pgdown space shortcuts seek/pause in the movie, but instead work as expected in the context of a Gtk widget (pause becomes a way to (re)start a movie stream in the playlist); moreover, the movie cannot be focused. To return to "usual" binding behaviour, the needs to hide the playlist. This seems like a reasonable solution to me, and this is essentially what Parole does minus the down/up binding and impossibility to focus the stream while the playlist is visible. > I think that's something that's a bit too hard to guess for the > average user... > > I personally second the up/down shortcut, but for now we've settled on a > compromise. > Yes, we did settle for a compromise but I was wondering whether things could be marginally improved.
> This seems like a reasonable solution to me, and this is essentially what Parole does minus the down/up binding and impossibility to focus the stream while the playlist is visible. This is actually a bug that should be resolved in a 0.5 maintenance release. I'm adding a separate bugreport to track it.