GNOME Bugzilla – Bug 405027
Key presses during rubber banding
Last modified: 2007-05-09 14:05:07 UTC
(Filing in general, since it affects both GtkIconView and GtkTreeView). When pressing a key, for example one of the arrow keys, while rubber banding, it moves the cursor + focus as expected in both GtkIconView and GtkTreeView. The widgets are then actually left in a kind of weird state, a rubber band with nothing selected, and a focussed/selected item out of the rubber banding bounds. One solution might be to disable the arrow keys (and other selection/focus affecting key presses) when rubber banding is enabled -- this is also the solution which both Mac OS X and Windows use. Better suggestions are always welcome ;)
(In reply to comment #0) > (Filing in general, since it affects both GtkIconView and GtkTreeView). > > When pressing a key, for example one of the arrow keys, while rubber banding, > it moves the cursor + focus as expected in both GtkIconView and GtkTreeView. > The widgets are then actually left in a kind of weird state, a rubber band with > nothing selected, and a focussed/selected item out of the rubber banding > bounds. > > One solution might be to disable the arrow keys (and other selection/focus > affecting key presses) when rubber banding is enabled -- this is also the > solution which both Mac OS X and Windows use. > > Better suggestions are always welcome ;) the suggested solution sounds good to me, especially sinc eit's precedented on MacOS and Win32. can you cook up a patch for that?
sounds good to me too. just make sure we still have a key combo to stop the rubberbanding.
Created attachment 87865 [details] [review] patch Disables all key bindings on GtkTreeView/GtkIconView during rubber banding, ESC stops the rubber banding.
Looks ok to me, although we might consider making the cancel-rubberbanding a keybinding, rather than hardcoding Escape
(In reply to comment #3) > Created an attachment (id=87865) [edit] > patch > > Disables all key bindings on GtkTreeView/GtkIconView during rubber banding, ESC > stops the rubber banding. looks good to me, should go in. (In reply to comment #4) > Looks ok to me, although we might consider making the cancel-rubberbanding a > keybinding, rather than hardcoding Escape that is unfortunately not really possible, in order for bindings to work, they kay press handlers have to chain up, but then we can't block "all" keys except escape. in order to do that properly, the exact binding that exists would have to be known before chaining up and doing the actual binding lookup. so i guess we really have to bite the apple here and stick with a hard coded Escape key.
ah, bummer. you're right
Committed on trunk (r17807).