Re: [Gimp-user] Restricting tool movement along a single axis

[Dominik Tabisz <d kupka1 gmail com>]

hi

Such tool option: "move by guide" / "move by path" would be appreciated.
One thing is primary problem: moving tool or handle (like in
perspective tool) along single axis. Something like this (or adjusting
behavior while pressing Ctrl) would be really usefull.

Another thing is to look at this problem from different point of view.
IMHO we deal with one example of slightly different problem.
Maybe developement is in so early stage that I could suggest slightly
different approach.

Imagine that we put on our graphic tablet  triangle (or any
other tool from technical drawing tradition). We could get desired
effect of restricting pointer movement. In fact we'd restrict
tablet/pointer movement to the edge of template/ruller.

In digital graphic we use guides, mesh, paths or selection/quick mask.
Each of these tools behave like our virtual template but for different
tasks. They mostly affect tools.
Why dont make one tool that will affect not tools, but pointer? Why
don't add easily adjustable input for this new tool - like paths? We
could use predefined "pointer restricting paths" or easily prepare new
one by preparing such path in Gimp, Inkscape or any other path
creating software.

Don't get me wrong - i like idea of improving tools. I would like even
more improving them in more "user adjustable way". And i'm pretty aware
that every such change will have dramatic consequences in someones
workflow.

For example Ofnuts mentioned handle behavior in perspective tool.
I understand - it's frustrating when You have to precisely catch
center of the handle and later move it to guides.

On the other hands this behavior let me catch any point within
selection and position it in new place. I do a lot such things while
adjusting perspective in photographs of paintings, documents etc. - In
photographs of my painting i catch the corner of painting, not the
corner of photo.

I do simple perspective correction to guides -
everything around painting will be cut away later. I dont want to
reshape selection at this stage, because later another tool is applied
(bent between paths).

While leaving this behavior as it is - i'll save my fast correction
technique, and Ofnuts will be dissapointed. While changing it to
automatic moving center of nearest handle to exact pointer location,
problem mentioned by Ofnuts will be solved ... and I'll lost my
primary tool.
When we get some modifier key, that will allow to move pointer to
center of a handle instead of moving the handle itself - we will both
get our desired functionality.
This compromise require change in thinking - we could use pointer as
input device, and modify it's XY input.

Is such change in understanding pointer behavior possible? Or we are
sentenced to compete which workflow, which task is more important?
Hope we can find a compromise that will be possible to code.

Dominik Tabisz