Hi, all

I'm working on a patch which shifts the rotation grid so that a grid 
intersection always falls on the center of rotation.  The simple use-case for 
this functionality is when doing a corrective rotation in a photo with a clear 
horizontal or vertical object.  Maintaining an intersection on the center of 
rotation means that you'd _always_ be able to stick the center of rotation on 
one end of the straight object, align a gridline along the object, and be done. 
  Currently, this is not always easily doable without futzing with the number 

My current rough-draft patch (against r28237) is up at:

At the moment I have a few questions:

1) Let C be the coords for center of rotation, and TC be the coords for the 
transformed center of rotation.  At times, it seems like TC is up-to-date and C 
lags (such as when dragging the center of rotation with the mouse).  But other 
times, C is up-to-date and TC lags (for instance, when adjusting one of C's 
coords with the spinbox in the dialog).  This makes it incredibly difficult to 
make the offset always correct.

I think this happens because gimp_transform_tool_grid_recalc() and 
gimp_transform_tool_transform_bounding_box() need to be called in differnet 
orders depending on where the canonical center of rotation coords are stored (C 
or TC).

When you update the spinbox, the gimp_transform_tool_motion() callback calls 
gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and 
then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then 
..._transform_bounding_box().  So, in this case, TC will be stale at the point 
when ..._grid_recalc() is called (since TC is updated from C in 

When you move the center of rotation by dragging it with the mouse, however, it 
seems that sometimes ..._transform_bounding_box() is called without an 
accompanying ..._grid_recalc() call, which means that C is stale but TC is 
up-to-date.  In particular, when this happens, C is temporarily set to the 
center of the image, which I find incredibly confusing.  I'm not sure how or 
this happens.  Any suggestions for how should I fix this behavior so that it's 
correct in either case?

2) I want to only enable shifting when we're doing rotation (as opposed to 
shearing or scaling, for instance).  This is as easy as clamping x_off and 
to zero in gimp_transform_tool_grid_recalc().  From that function, how do I 
determine if the transformation is a rotation?

3) The bounding box is drawn in a different function.  I would like to avoid 
splitting the shift logic across functions (or duplicating it in both).  Any 
suggestions on how to keep the bounding-box aligned with the grid (including 
shift offset), but still allow the bounding box to work when the grid isn't 
being calculated?

4) Any other questions, suggestions, or feedback?

Gimp-developer mailing list

Reply via email to