GNOME Bugzilla – Bug 8269
Hitting Edge with Brush Creates Looooong Strokes via Autoscrolling
Last modified: 2005-01-02 21:20:00 UTC
package : gimp Name........: Garry R. Osgood Email.......: gosgood@idt.net Platform....: SGI O2 IP32_5k SGI Indigo IP20 Irix 6.5.6f GIMP Version: 1.1.19 to ChangeLog CVS 1.2494 GTK Version.: 1.2.7 Severity....: wishlist -- Tools ought to "own" the ability to induce autoscrolling of the window over the canvas. Currently, it seems that every tool induces automatic scrolling; this is very nice when making a rectangular selection and the layer is very much bigger than the display: hitting an edge causes scrolling in that direction. The exact same feature is not so very featureful when the tool in question is a brush; when a brush hits an edge, causing scrolling in that direction, the brush stroke does not turn off, the stroke persists as autoscrolling cycles, creating a (rarely useful) streak across the layer. If autoscrolling could be retained for tools where it made sense and (optionally) supressed where the same behavior is questionable, then I think the wish could be democratically fulfilled. -- Other system notes: None pertinent. -- -- How to repeat: 0. Create/get any large image (say 1200 X 1200) 1. [Optional] Zoom to a large magnification. This is not necessary to reproduce behavior, but it illustrates the condition more readily 2. Position window near an edge or corner. of the layer (Say, the northwest corner) 3. Select a brush/pencil/ink tool 4. Draw stuff; pull a stroke past a window edge, opposite from the layer edge (say, the south or east edge) triggering autoscrolling 5. Scrolling commences, brush tool remains in motion mode, ink gets spilled in a long streak. 6. Cuss a little. 7. Hit control Z. 8. Learn to color within the box, as taught in primary school. 9. Write a wishlist report. -- -- Other comments: Debated with myself if this is a bug or a wish. Observed segfaults on rare occasions when inducing this behavior, but I can't reliably reproduce it. ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 10:50 ------- This bug was previously known as bug 8269 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=8269 Originally filed under the gimp product and general component. The original reporter (gosgood@idt.net) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, egger@suse.de.
Adding an optional empty area between the image and the scrollbars (as discussed recently on the gimp-developers mailing list) would also solve this problem.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Reassinged to current CVS because it's a wishlist item.
Autoscrolling with a paint tool is a useful option, however right now it scrolls brokenly fast. Many paint programs will scroll when the tool hits the edge, just at a reasonable rate instead of the absurdly fast rate that the current gimp does. I really see this report as two parts: * bug: scrolling is absurdly fast This bug is really annoying because it can mess up a perfectly good brush stroke. When a stroke is quite long and intricate, having to undo it and redo the whole thing because you hit one pixel over too far causing the brush to rocket across the image is extremely irritating. This is a real bug and should be fixed in 1.2 if at all possible. * wishlist: allow user to set autoscroll on all tools. This is trivial in the 1.3 codebase. We can just add it as an option in the tool dialog. You might also consider: * wishlist: autoscroll speed preference. While no one in thier right mind would want the current speed, some people might like it faster than others. Also, different images/tools might require faster/slower autoscroll. Actually, this could be done by using a slider in the tool options box.
I see this as a bug, even if it's a biggish one. I don't think it would be wrong for a fix to this to go in after a feature freeze. Changing milestone to 2.0. Dave.
Bumping milestone to 2.2. If someone starts working on this they can change the milestone as appropriate. Dave.
It strikes me that (a) this is actually a bug, not an enhancement, and (b) the easiest and actually best solution is just to disable autoscrolling for the paint tools. If this is acceptable, I can probably implement it.
I think we would accept such a patch, it seems like the right thing to do.
Created attachment 26637 [details] [review] patch to gimp/app/display/gimpdisplayshell-callbacks.c This patch against current CVS implements smooth autoscrolling of the image for all tools that cause scrolling when moved out of the image with button1 down. It does this by starting a timeout and running it until either the mouse re-enters the image or button1 is released. It also has the sort of interesting side-effect of permitting tools to continue to act outside the visible area, so long as the mouse button is held down. (Note: the patch was tested against 2.0.0.)
I don't understand your comment about the "interesting side-effect". You can do that without your patch also. Anyway, I am going to try your patch now.
It's a little late to get this into 2.2 still. Moving to the Future milestone.
Okay, I have committed an updated version of the patch (which uses a timeout to control the rate of autoscrolling). It is updated in three ways: 1) Follows GIMP coding style, which I didn't perfectly understand when I wrote the first patch. 2) Deals with bitrot. 3) Makes scrolling rate proportional to the distance of the pointer from the edge, which I think feels nicer. Of course I am willing to tweak the code or revert it if people feel that there are major problems with this solution. In any case, I will leave this bug report open for a few more days. For CVS head: 2005-01-01 Bill Skaggs <weskaggs@primate.ucdavis.edu> * app/display/gimpdisplayshell-callbacks.c: use a timeout for autoscrolling, to fix bug #8269. Happy new year!
Okay, since Sven has tried this and fixed the things that didn't work quite right, let's call it FIXED.
Well, the code was still quite a mess but Mitch fixed that by now.