GNOME Bugzilla – Bug 53988
Should implement scrolling with arrow keys
Last modified: 2004-07-29 16:46:08 UTC
(This modification to Gimp-1.2.1 reduces the time it takes me to clean up 600 dpi scans by an order of magnitude!) It hooks the standard arrow key function (that normally does nothing) to something of mine that scrolls the current window according to the arrow key (or keypad arrow key) being pressed. By default it scrolls by half the screen width/height, but holding down the shift key moves by a pixel.
Hmmm... The patch was not included in your bug report. The only thing that is included is the URL of the diff file, but not the file itself. Since this URL refers to your local disk, it cannot be used by anybody but you. Could you attach your patch to this bug report? Follow the link "Create a new attachment" and use that form to upload your patch.
Created attachment 516 [details] [review] Patch provided by "cjb" in URL. (7 Kb)
Reassigned to current CVS because it's a wishlist item.
It's actually not that easy since the arrow keys are already used by quite a few tools. I suggest the reporter tries to get his hand on a wheel mouse to clean up his scans.
*** Bug 62849 has been marked as a duplicate of this bug. ***
If the arrow keys are used by other things then it might be necessary to cleanly seperate out the different contexts. It would Page Up and Page Down should definately be used for this (and hopefully my scroll mouse will also work) Using Ctrl to Modify page up down to go in smaller increments sounds good, but moving only a single pixel seems almost too fine grained. Something sensible could probably be done with the Home, End Keys. In most applications the Home key brings you right to the top of the Document and the End key to the very End. For sideways scrolling some apps use Ctrl + Left Arrow. Ctrl + Right Arrow. It would be kinda neat if the arrow keys could be used to nudge the current selection by small amounts. The smartest easiest* thing to do would be to see how and what Adobe Photoshop, Corel, Paint Shop Pro, etc. do and then embrace and extend. (asking usability@gnome.org might not be a bad idea either). If i have time i will try and do a behaviour comparision and add it to this report.
I'm sorry but Page Up/Down is used already.
Sven could you please elaborate. I am using an older version of Gimp (1.2.3) and i cannot see what Page Up and Page Down are being used for. Using Page Up and Page Down for something other than going up and down the page seems unwise (usability, consistancey with other applications), although it might be reasonable. I would hope that you would not rule out changing keybindings just because the keys are already in use, although it is understable that any changes would have to be very carefully considered to minimise any confusion to existing users, and provide a significant benefit.
Take a look at menurc: ;(menu-path "<Image>/Layers/Stack/Previous Layer" "Prior") ;(menu-path "<Image>/Layers/Stack/Raise Layer" "<Shift>Prior") ;(menu-path "<Image>/Layers/Stack/Layer to Top" "<Control>Prior") ;(menu-path "<Image>/Layers/Stack/Next Layer" "Next") ;(menu-path "<Image>/Layers/Stack/Lower Layer" "<Shift>Next") ;(menu-path "<Image>/Layers/Stack/Layer to Bottom" "<Control>Next")
I use this a lot and I know of other people that do. IMO the use of PageUp / PageDown for manipulating the layer stack makes a lot of sense.
Do you think manipulating Layers a more frequent action than moving up and down the page? Would it not be more obvious and (new) user friendly? I dont deny that the current setup is useful (but i dont user layers much). Are layers so useful that all the options merit keybindings. Perhaps the unmodified Page Up and Page Down could be used for scrolling and the Shift/Ctrl modified ones left for manipulation layers? Are these really the best defaults? If Page Up, Page Down were used for scrolling by default would users who do a lot of work with layers still be able to override the defaults? Also, I think it is pretty confusing to have the shortcuts for these buttons labelled as 'Next' 'Prior' but perhaps this is a historical Unix convention i am unfamiliar with. I will file a seperate report requesting this to be changed if you dont mind.
The names of the keys are an GTK+ issue. We are unable to change them in Gimp without major kludges. And yes, I think that Layers are much more important than scrolling. We already have at least three very convenient ways to scroll (wheel on mice, Preview in the lower right of the image window, middle mouse button in the window) so that sacrificing the very logical Page Up/Down for this (which would not solve horizontal scrolling btw). However, keyboard shortcuts for scrolling would be nice, but they should not default to PageUp/Down or the cursor keys.
The suggestion of binding Ctrl or Alt-arrows would be inconvenient, as many existing window mangers use these for workspace switching, and it is bad interface design to have an application grab common desktop keyboard shortcuts for itself. My patch/suggestion imitates the behavour of Paintshop Pro (at least). The suggestion that I should go out and buy more unnecessary hardware was offensive. (Note the change of URL for the patch.)
Oh, come on, it wasn't meant as an offense. If you'd try GIMP with a mouse with scroll-wheel you'd find that it is actually a useful piece of hardware.
(Tell me somewhere that sells a three-button + wheeled trackball, that doesn't sell for 8 weeks' worth of food money...) IMHO it's still a Big Win to provide this key shortcut, as it allows both hands to be used 'in parallel' and 'modelessly', unlike with a wheel-mouse, that requires a 'Mental Operation' of about 1.25 seconds each time you swap between using the mouse for erasing and then for scrolling. When cleaning up 1200 dpi scans, those seconds add up.
I have thought hard about this, I left it at the back of my mind and I tried to divine what the true problem was. Let me put it to you like this, if you did what cjb and I are asking for by default and other dont like it they can at least rebind the keys back to moving between layers. But if you leave the current situation as it is, cjb and I cannot rebind the keys to do what we want*. If there was some way that we could (re)set/change the key controls of features that dont have menu items without the need to recompile then this would not be a problem. How can make it work for all of us? [* at least, not without significant difficulty such as a recompile or putting together some bizzaro plugin]
For those of us who are working on *real* images, the default arrow key behaviour is really bad. Moving layers take a *long* time, and the operation shouldn't be bound to keys that are easily pressed by mistake, or because most users expect them to do something else.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
The URL field has been removed from bugzilla.gnome.org. This URL was in the old URL field, and is being added as a comment so that the data is not lost. Please email bugmaster@gnome.org if you have any questions. URL: http://hunter.apana.org.au/~cjb/Code/gimp1.2.3-arrow-keys-scroll.diff
" If there was some way that we could (re)set/change the key controls of features that dont have menu items without the need to recompile then this would not be a problem. " isn't this the sort of thing handled by gtkrc 'bindings'? is it possible to hve bindable shortcuts that don't have keys assigned by default? would this allow people who want this to, for example, bind scrolling to the numberpad arrows? does gtk allow to distinguish between numberpad directions and cursorkeys? i find they are interpreted as the same key unless i have numlock on, in which case numberpad produces the expected 8,4,6,2 numbers for the directions. this is a bit hackish but would work.
Fixed in CVS: 2004-07-29 Michael Natterer <mitch@gimp.org> * etc/controllerrc: changed default configuration of the keyboard controller: scroll the display one step on cursor_key, scroll by one page on <shift>+cursor_key and scroll to top/bottom/left/right on <control>+cursor_key. Fixes bug #53988. Moved the old opacity-modifying actions to <alt>+cursor_key.