Re: handle transform tool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2015-03-06 at 23:33 +0300, Alexandre Prokoudine wrote:
> Hi,
> 
> Here's some first feedback regarding the newly added handle transform
> tool. Pleas bear in mind that it's just my personal observations, I
> could be dead wrong about something.
> 
> I see that the new tool might have some uses (personally, i'm
> struggling with finding those, even after watching
> https://vimeo.com/82585231, but that's my problem), but there are a
> few issues in this tool regarding consistency and logic of operation.
> 
> The way it works right now is:
> 
> 1) Once you switch to it, the default mode is transformation. However,
> there is nothing to use for transformation, because there are no
> handles. This is problem #1: defaults don't make sense and demand
> extra clicks for no good reason.
> 
> 2) So you switch to the mode to add/adjust handles. Pressing shift and
> clicking the first time does nothing. You have to click the second
> time to actually add a handle. This is problem #2: an extra click for
> no good reason.
> 
> 3) After you added four handles, you cannot add any more handles, but
> there's no indication of that (we usually use the status bar and
> change tool's mouse pointer for hints like that). This is problem #3:
> no user support with hints how to use the tool.
> 
> 4) With four handles, it's too easy to completely mess up and end up
> with an invisible layer. Here's an example. Original position of four
> handles:
> 
> http://i.imgur.com/04f1t4j.png
> 
> And now after unfortunate tweaking of the position of the lower right handle:
> 
> http://i.imgur.com/XKUqiGH.png
> 
> Yeah, I know: "well, don't do that then", but isn't there a way to
> figure out that the current position of a handle doesn't make sense,
> and then stop movement of the handle and, I dunno, flash the outline
> of the layer (made by the transfomation cue) with red for visual
> warning? it's just an idea.
> 
> Now, compare that to the Cage transform tool that was designed by Peter:
> 
> 1) Default mode is adding cage vertices. Makes a perfect sense.
> 
> 2) You only need to click once on the canvas to start adding vertices.
> Again, exactly right.
> 
> 3) Once you closed the cage, the tool automatically switches to
> transformation mode all on its own. Makes a perfect sense again. (Hard
> to compare to handle transform tool which can have 2 to 4 handles,
> depending on what the user needs, but you get the point, eh?)
> 
> Let's get back to handle transform's issue #1. Since it's up to the
> user, how many handles should be added, making the add/adjust mode the
> default one doesn't make sense either:
> 
> - if it's the default one, then it's the one where user spends most
> time, therefore it should have no modifiers, whereas the move mode
> should get one. But it's unlikely that users will spend most of their
> time adding and adjusting handles rather then tweaking the actual
> transform (this, of course, is subject to testing, and I'm merely
> speculating).
> 
> - if we don't assign any modifiers to modes at all -- the way we do
> with the Cage transform tool (and it's an issue as well) -- it means
> we force users to rely on mouse-clicking rather than using convenient
> and consistent modifiers.
> 
> As you can see (or maybe not :)), neither of the modes in the handle
> transform tool is a sensible choice to be the default one, and
> operating the tool is full of extra clicking and surprises.

Much of the above is true, but that's not why I'm replying.

> With Peter's departure I don't really have a suggestion how to deal
> with this kind of a situation. It's great that people contribute code,
> and I'm thankful to them. But do we want to pile underdesigned
> features up again? Personally, I wouldn't like to see the project to
> go back to pre-2006.

As said on IRC, we have the playground now. The only reason why you
are able to write this mail is because the code is now ready to
try for *everybody*

- not only to people who apply a rotten patch from bugzilla
- not only to people who check out and bulid a branch

The sum of these "not only" people is close to zero.

So now we have some new code, in the playground, so that it will
be off by default in a stable release. Everybody can try it, we
can improve it, you can complain about it.

What's the purpose of having the playground if it's forbidden
to play on it?

Pre-2006... WTF.

Mitch


_______________________________________________
gimp-developer-list mailing list
List address:    gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list




[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux