After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 329817 - Crop tool's reported sizes should stop at image edge
Crop tool's reported sizes should stop at image edge
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal normal
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-02-03 18:41 UTC by Akkana Peck
Modified: 2006-06-12 16:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch: show only effective image in the status bar (1.22 KB, patch)
2006-02-04 04:55 UTC, Joao S. O. Bueno
committed Details | Review

Description Akkana Peck 2006-02-03 18:41:33 UTC
In the new crop tool, if you crop to the edge of the image, there's no way to find out for sure how big the resulting image will be, and the numbers that are reported are wrong.

Start anywhere in the image, then drag down and to the right. Watch the width and height numbers (in the status bar and in tool options) as you drag. Keep dragging until the mouse is outside the image window. Eventually width and height are reported to be larger than the actual image dimensions. This is wrong: if you finalize the crop, the resulting image has not been enlarged, but is cropped only to the boundaries of the old image (as it should be).

Please make the reported numbers stop at the image boundaries (on all four sides) so that it's possible to predict from those numbers how big the cropped image will be.
Comment 1 Joao S. O. Bueno 2006-02-04 04:55:31 UTC
Created attachment 58688 [details] [review]
patch:  show only effective image in the status bar

Afects the new rect. select tool as well (as this is what the crop tool uses)

For some reason, the coordinates were only being updated  if the movement was in the upper-left or lower-right direction. I changed that too.

I opted to make the display change only to the status bar, as the coordinates on the tool options dialog will be needed as a reference if one decides to type the rect. size by hand, and moving it afterwards.
Comment 2 Carol 2006-02-04 05:37:50 UTC
2006-02-03  Carol Spears  <carol@gimp.org>

	* app/tools/gimprectangletool.c: Applied patch from Joao S. O. Bueno
	Calligaris that corrects status bar coordinate display
Comment 3 Michael Natterer 2006-02-04 15:19:46 UTC
While this might be the right thing to do for the crop tool, it's a
regression for rectangular and ellipse select. The change as in
CVS affects both crop and new rect select, it needs to be re-done
to be configurable on a per-tool basis, or reverted for the time
being until a better solution is found.
Comment 4 Michael Natterer 2006-02-04 15:21:30 UTC
See bug #326450 for the reasoning of reopening this bug.
Comment 5 Joao S. O. Bueno 2006-02-04 16:49:43 UTC
I've seem the other bug, and thought about the subjetc, and tried with the rect tool.  
IMHO, the changes should be  kept. Actually, it just looks like it fixes  bug #326450 as well, if I figure out correctly what are the reporter wishes there.

It even is a nice work around for another bug about making the crop tool stopping at the image border when fixed aspect ratio is selected., as there is a visible feedback of when that happens. (could not find this other bug in a reasonable amount of time)

Comment 6 Akkana Peck 2006-02-04 19:09:42 UTC
It sounds to me as if the requestor of bug 326450 ultimately wants exactly what I want, which is for the status line to reflect what the real rectangle will be, not the mouse position even if it's outside the boundaries of where the rectangle will be. That makes the most sense for both crop and rect select.

Reverting Joao's fix won't help bug 326450; that bug happens both before and after Joao's change. It looks like a fix for that bug would require additional work.
Comment 7 weskaggs 2006-05-31 19:49:29 UTC
I have committed a set of changes that hopefully will satisfy everybody's needs.  The approach is to add a new "constrain" property to GimpRectangleTool that determines whether to clip at the image bounds when computing dimensions.  I suspect mitch might think the handling of rectangle-select is wrong here, but I'm not quite sure why he would think that.

From the HEAD ChangeLog:

2006-05-31  Bill Skaggs  <weskaggs@primate.ucdavis.edu>

	* app/tools/gimprectangletool.[ch]: add "constrain" property
	to specify whether to clip at image bounds when computing
	dimensions.
	
	* app/tools/gimpcroptool.c
	* app/tools/gimpnewrectselecttool.c: set "constrain" to TRUE.
	
	* app/tools/gimpellipseselecttool.c: set "constrain" to FALSE.

	Hopefully fixes bug #329817.