GNOME Bugzilla – Bug 35489
crop tool doesn't always change canvas size - problems with undo and Ctrl
Last modified: 2003-10-16 10:44:10 UTC
Package: gimp Version: 1.1.30 Sometimes the crop tool will also change the canvas size when it crops, sometimes it won't. It seems to depend a bit on the image size (or possibly the redraw speed). A demonstration of this: 1) start gimp. 2) create a new RGB image, 1600 x 1200 3) paint a squiggle so you can tell which part of the image you're looking at 4) crop a rectangle out of the middle >>> Notice the window shrinks to the cropped portion, and it has the yellow layer boundary lines around it. 6) ctrl-Z to undo. Window resizes correctly etc. 7) crop pretty much the same rectangle again. >>> Notice the cursor flickering between a watch and the crop cursor as the background redraw updates the screen. This is ugly and quite possibly slowing down the redraw. BUG: The window shrinks etc as before, but now you don't have the yellow layer boundary lines. Zooming out shows them to be in the grey area, outside the paintable area. It looks like the layer size has been changed but not the image size. The real problem is this lack of consistency. If you repeat the undo-crop cycle, it seems that it works correctly odd times, and goes wrong even times (eg works 1, 3, 5 ...). Austin ------- Additional Comments From austin@gimp.org 2000-12-18 06:53:33 ---- Subject: Re: Bug#35489: crop tool doesn't always change canvas size From: Austin Donnelly <austin@gimp.org> To: 35489@bugs.gnome.org Message-Id: <14909.64189.321698.938441@hornet.cl.cam.ac.uk> Date: Mon, 18 Dec 2000 11:53:33 +0000 On Monday, 18 Dec 2000, Austin Donnelly wrote: > Sometimes the crop tool will also change the canvas size when it > crops, sometimes it won't. > > It seems to depend a bit on the image size (or possibly the redraw > speed). A bit of further investigation shows that it's to do with the fact that holding down ctrl to type ctrl-Z for undo also toggles the crop / resize tool modifier. It seems that because the redraw takes too long(?) the ctrl key up event is lost so the toggle stays in the opposite state. With small images, somehow this doesn't happen. Wierd! Austin ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 11:05 ------- This bug was previously known as bug 35489 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=35489 Originally filed under the gimp product and general component. The original reporter (austin@gimp.org) 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.
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
I tried to reproduce this with 1.2.3-pre2 (running on Solaris 8) and I did not have that problem. Maybe the bug is gone now? Can anybody test it again and see if the bug is still present?
I can still reproduce it with 1.2.2 on linux RH71. At stage 6), you need to: 6.1) hold down control 6.2) tap Z (undo) >>> window enlarges, and screen repaints in large squares 6.3) let go of control (you must do this while the repaint is still in progress) ### bug: notice that the crop/resize toggle in the tool options dialog did not go back to crop when you let go of control Somehow, the "control key up" event gets lost if it happens while the view is repainting. This is why you need a nice big image (or slow machine) to reproduce this race. I'm using a PII 300MHz. I haven't had a chance to look at 1.2.3preNN yet, but hopefully I'll be able to give it a spin soon. Austin
Yes, you are right: the bug is still in 1.2.3-pre2. I tried it again on Solaris using a 2000x2000 image, and I could reproduce the bug easily. I could even reproduce it with the default image size (256 x 256) as long as I released the Ctrl key fast enough. I also tested it under Linux, so this does not depend on the OS, X server or window manager. If you have the Tool Options window open when you undo, you can see that the mode is toggled and not restored correctly. So as you wrote, it looks like the Gimp does not correctly update the state of the Ctrl modifier when redrawing/undoing. This can be rather confusing for the user because if the tool is stuck in the "wrong" state and the user does not even know about the two modes for the Crop tool, then all other crop operations on the same images and other images will give unexpected results. And with version 1.2.2 that does not include the fix for bug #51114, it can lead to incorrect data saved in the image files.
This Ctrl key bug can also affect other tools: I tried the same steps as above, except that I switched the active tool to the Flip tool or Magnify tool just before the undo in step 6. In both cases, the current mode of the tool was toggled after the undo. And this is not even related to an undo step after cropping. Here is a different scenario that gives the same result: A) Create a new image, 2000 x 2000 B) Scale it down to 200 x 200 C) Select one of the tools that has a Ctrl toggle: Magnify, Crop, Flip, Bucket Fill, Eraser, Convolver or Dodge and Burn D) Undo After this, the current mode of the tool will remain toggled. So the bug is related to the undo step, or maybe even to any operation in the core that causes a long redraw during which one modifier key is released or pressed (I haven't tested this). This could also explain some previous bug reports (on the mailing list and in the gimp newsgroup) about the Eraser switching to anti-erase mode. The Crop tool and the Eraser are probably the tools on which the effect is the most likely to be detected.
*** Bug 65252 has been marked as a duplicate of this bug. ***
*** Bug 86376 has been marked as a duplicate of this bug. ***
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
This bug has apparently been fixed by the various stuck modifier fixes which are in 1.3. Won't be fixed in 1.2 because that code is more than hairy and fragile.