Sven Neumann writes: > http://gui.gimp.org/index.php/Specifications [ ... ] > The other aspect is not yet implemented. The spec suggests that when the > mouse is over one of the corner or side handles, and one of the cursor > keys is pressed, the rectangle shall be resized by one (shift: 15) image > pixel in that direction and (new) the the canvas shall be scrolled in > such a way that the position of the bounding rectangle under the sprite > shall be constant. > > I don't think that scrolling the canvas is a good idea. If the canvas isn't scrolled, the spec should probably mention what happens on the next keypress. Suppose I have the mouse cursor over a side handle and I press right-arrow. The side handle moves right by one image pixel. Now the side handle is no longer under the mouse. If I press right-arrow again, I hope it would move another pixel, since arrow keys aren't very useful if you can only move one step. But that requires that the tool go into "keyboard navigation mode" where the tool remembers that one handle is active and is subject to being moved by arrow keys even if the mouse is no longer over that handle. How will the user see that it's in that mode? I'd suggest keeping the handle outline bold with the 2-pixel border described in the spec, even after it moves out from under the mouse cursor. But if the mouse moves (more than some threshold?) then un-highlight the active handle and go back to normal mouse-activated mode. Of course you could warp the mouse cursor to follow the handle, but I doubt anyone wants to do that, especially in an app used with graphics tablets. -- ...Akkana "Beginning GIMP: From Novice to Professional": http://gimpbook.com _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
