GNOME Bugzilla – Bug 579319
global keyboard shortcuts should apply only when the timeline is focused
Last modified: 2014-02-28 18:47:48 UTC
It seems that keyboard shortcuts (such as left/right arrow keys) are bound to the entirety of the UI. So if the media library or the toolbar is focused and you want to move between items, each time you do so, the timeline will also try to move forwards/backwards. Keyboard shortcuts like this should not be active when manipulating other parts of the GUI (toolbars, prefs/rendering dialogs, source list, etc.)
We currently have a number of "keyboard shortcuts", most of which are bound through the menu system. Which keyboard controls should be affected by this? Just the arrow keys? What about using the space bar play/pause? Are there any other menu shortcuts in this category? Furthermore, let's say that I were to make the arrow key seeking only work when the timeline is focused. You still have the same problem of not being able to use arrow keys to unfocus the timeline. Since the whole concept of focus is pretty subtle, I anticipate this causing problems for users. Sometimes the timeline will be focused, and arrow keys will move the playhead. Other times the timeline will not be focused and arrows will change widget focus as they normally do. I don't like this inconsistency. Perhaps some other scheme should be used? I have been thinking for some time that unmodified arrow keys shouldn't be used as shortcuts at all, sticking instead to shift, control, and shift+control. Or we find some other key set to use for seeking like < and >. It might be nice to use arrow keys to focus clips within the timeline, for example.
pushed branch fix_579319 to my repository. let me know if I got it right or not.
That branch fix makes sense to me in how it behaves. I'd perhaps add the spacebar to the list of excluded things (as you suggested in the previous comment - sorry for not replying, I thought you were asking others), but that will need to be tested as well. At least the current behavior with arrow keys seem to be good, except one detail: there is something strange with how the focus is grabbed (or not) by the ruler. Sometimes when I click on the source list and then on the ruler (instead of the timeline canvas), I can scrub with the arrows, but sometimes not. I have not quite figured out the logic behind it.
Interesting, i'll look into that. It will probably to display a focus ring around the timeline / ruler, but as with many things it's not as easy as it looks, and the naive approach doesn't seem to work.
Original issues fixed with these commits. I also added a try/except around the seeking code to avoid the UI going nuts. Might fix the issues mentionned in comment #3. If not.. please open a new bug :) commit d1f1fd910c53a4b988e54d35216bacebc4d6a585 Author: Edward Hervey <bilboed@bilboed.com> Date: Tue May 19 19:55:10 2009 +0200 ui.timeline: optimize key handling seek code a bit more. commit 592986c5e125379f847880f872ecec7c0345dbe0 Author: Edward Hervey <bilboed@bilboed.com> Date: Tue May 19 19:54:44 2009 +0200 Pipeline: Catch/debug exceptions from queries on the gst.Pipeline commit 31109323fe70414db10e4826e09dd6caaaf779d5 Author: Brandon Lewis <brandon_lewis@berkeley.edu> Date: Fri May 15 16:02:31 2009 -0700 ui: seek only when timeline/ruler has focus. Fixes #579319. Also move keyboard seeking to ui.timeline.
I encouter this bug as described in the original report in Pitivi 0.92 on fully updated f20.
Re-fixed with: commit 5ffd50e208d8872b555d2c60b24256c015c0e762 Author: Alexandru Băluț <alexandru.balut@gmail.com> Date: Thu Feb 27 23:51:38 2014 +0100 timeline: Handle only the key-press/release events on the timeline Fixes (again) https://bugzilla.gnome.org/show_bug.cgi?id=579319