GNOME Bugzilla – Bug 78730
Add optional motion constraints to the Move Tool
Last modified: 2008-01-21 19:00:31 UTC
I would like this behavior which I've seen in many other programs: If I start dragging something with Shift held down, it constrains motion to be along the axis of my first motion. So if I start moving horizontally, I can only move horizontally, and the vertical position will not change.
I assume that you would like this feature to be added to the Move tool. There is already a similar feature included in some tools (constraining the angle or constraining the movement along the vertical or horizontal axis) although different modifier keys are used. The Shift modifier is already used by the Move tool (to select the current layer even if you click in a transparent area), so I do not know what could be used instead. We have to select a consistent set of modifiers that are as similar as possible for all tools. See also bug #51108 describing some of the problems with the modifiers and other hidden options for the tools.
> The Shift modifier is already used by the Move tool (to select > the current layer even if you click in a transparent area), Oh, neat, I didn't know it did that. > so I do not know what could be used instead. We have to select a > consistent set of modifiers that are as similar as possible for all > tools. Indeed; though it seems to me that constrained motion, since it's implemented by multiple tools, ought to take priority over tool-specific options like layer locking. So I'd move the layer locking feature to another key, and use shift for constraint, to be consistent across tools.
Since most tools use Ctrl for constraints, it would be more consistent to use Ctrl here as well.
Bumping to 2.2. Dave.
The move tool uses Ctrl and Alt to switch between the affected item (which can be layer, selection or path). This is however not consistent with any other tool. The transform tools use Ctrl and Alt for constraints so perhaps this could be done here as well.
Comments anyone?
Alt is used to move the selection in all selection tools and works consistently, we should not change it.
I agree. Ctrl and Alt for constraints sounds good. I don't know how we can have shortcuts for changing the affected item if we use them.
Ctrl and Alt for constraints?? Ctrl should be enough, Alt is already used for moving the selection (not its content).
In the absence of someone actively working on this, it doesn't make sense to keep it on the 2.2 milestone. Bumping to Future.
Upgrading target milestone from Future to 2.6.
Created attachment 98842 [details] [review] diff against svn trunk patch implementing horiz/vert-constrained movement when the Control key is pressed or held down.
Attached is a patch to SNV trunk that accomplishes this. It causes pressing or holding down the Control key to constrain movement to horizontal or vertical. I thought that would be most useful, but it would be easy to change the constraint to 45 degree increments, 22.5 degree, or whatever. Most of the changes are to app/tools/gimpeditselectiontool.c. Although the code there is applied to a lot of different, I believe the changes made here are unlikely to have bad side effects. There is of course one side effect: I had to remove the code that causes holding down Control to make the tool act on paths rather than layers. Ideally, GimpEditSelectionTool should probably be converted to an interface rather than a tool in its own right, but that's a whole different story...
Created attachment 101813 [details] [review] 001_move-tool-move-constraint.patch Here is a patch that uses an array of normalized vectors for defining on what lines that movement should be constrained. I have not removed the ability to switch to moving paths with the Ctrl key and instead switch between constraint and not constraint in _active_modifier_key. Not 100% sure if this is evil or not, I guess it could be a bit confusing. Would appreciate a review of this patch
Created attachment 101877 [details] [review] 001_move-tool-move-constraint.patch Same patch but cleaned up.
Part of the fix commited to trunk, rev 24622. 2008-01-15 Martin Nordholts <martinn@svn.gnome.org> * app/tools/gimpeditselectiontool.[ch]: Made it possible to constrain movement with the Move Tool in 45 degree angles by holding Ctrl when a move has been initiated. This fixes the essential part of bug #78730. Before closing this bug the constraints should be applied when a user merely toggles Ctrl i.e. without having to move the mouse first. Other things worth discussing might be if we want some other degree constraint than 45 degrees, and if it is acceptable to only be able to toggle constraint when the tool is active. Personally I don't consider the latter a big problem.
Commited to trunk, rev 24663: 2008-01-21 Martin Nordholts <martinn@svn.gnome.org> * app/tools/gimpeditselectiontool.[ch]: Moved the logic in _motion to a new helper function _update_motion that is also called in _active_modifier_key. Makes toggling Ctrl immediately apply/remove movement constraints for the Move Tool when a move has been initiated. This completes the fix for bug #78730. I'm closing this report now. We can take any discussions regarding the details of my fix in the IRC channel or on the mailing list.