GNOME Bugzilla – Bug 535924
Control Left/Right no longer skips
Last modified: 2020-03-17 08:25:30 UTC
<Ctrl> + left/right arrow keys used to skip back/forward in your current track - and the feature seems gone in 0.99.x
I'd like to confirm that this feature remains missing in SVN trunk. Could someone correct the version and mark it confirmed?
Confirmed, it does not work in trunk.
*** Bug 556984 has been marked as a duplicate of this bug. ***
*** Bug 558944 has been marked as a duplicate of this bug. ***
Personally I'd prefer a simple left and right arrow skipping method (without the control button), but most solutions are probably more intuitive than the 'n' and 'b' buttons. Wait, is it 'b' for back or 'p' for previous? And if it's 'b' for back, why isn't it 'f' for forward? ...which is exactly why we should just use arrow keys.
Using arrow keys without a modifier key interferes with navigating the interface using the keyboard. This is not only a keyboardability, but also a a11y issue I think.
What navigation is broken by using the arrow keys that isn't already (and arguably more intuitively) covered by tab and shift-tab? The only place that I see the left and right arrows being used is moving from the browser to the track list. Is there some other use that I'm missing?
E.g. while typing in input boxes. (Yes, you can work around it, but it's inconsistent in case e.g. the search box has focus.)
I don't think this would interfere with the input boxes. For example, there are a few actions which currently use keys without modifiers -- R for restart, S for focus search etc. You don't see these clashing with the search box because the search box automatically takes control of all of these actions when focused.
(In reply to comment #9) > I don't think this would interfere with the input boxes. For example, there are > a few actions which currently use keys without modifiers -- R for restart, S > for focus search etc. You don't see these clashing with the search box because > the search box automatically takes control of all of these actions when > focused. Yes, I know, and I do not like that either. It is non-standard behaviour for a Gnome application and interferes with (requested in another bug report) type ahead search-like functionality.
It is frustrating that some of those single-key shortcuts create problems with type-ahead, which is one feature that I still really wish Banshee would have. Certainly, though, we wouldn't consider using control-space to pause instead of just the space bar. Some things just seem more natural without modifier keys, and I would think that right/left for forward/back is an example of that. Either way, I have multimedia keys on my keyboard, so the right/left vs. control-right/left doesn't make too much difference to me. :)
I think what is most likely is that we'll do the type-ahead feature activated by / (then start typing whatever you want). Anyway, that's a separate bug.
FWIW, type ahead does not conflict with the space bar, since it makes no sense to enter a search that start with a space. This is exactly how Nautilus works. For example, open ~ in Nautilus. Click on "Desktop" to hilight it. Then - pressing Space -> goes into "Desktop" - typing a character -> opens up the type-ahead box
*** Bug 608551 has been marked as a duplicate of this bug. ***
Are any patches available to fix this bug? I would sacrifice navigation for ease of playback. I don't see how this is an interference issue when media players on other OSs work exactly this way. How do they get it to work?
Please leave the keybinding discussion out of this bug, as it is about the regression from 0.x series where <Ctrl> + left/right arrow keys just worked. I think the main problem here is the lack of functionality found in previous releases; the other topic just creates muddle and deserves separate bug. I hope it gets fixed for 1.6, having a string freeze in place. I really miss this bit!
the ability to skip backward or forward within a music track or video is still missing in Banshee 2.1 Many people use keyboards shortcuts, and this feature is important from the usability point on view. If this is going to be dropped from Banshee, is there any way those feature could be reintroduced in a pluggin ?
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.