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

On 03/08/2015 11:34 AM, Michael Natterer wrote:

So now we have some new code, in the playground, so that it will be off by default in a stable release.

A somewhat off-topic question:

I have the n-point deformation and handle transform checked in the playground and I restarted GIMP. But I can't find either of them anywhere in the GIMP menu.

How do you access the playground tools and options?

Elle

On Sun, 2015-03-08 at 17:11 -0400, Elle Stone wrote:

On 03/08/2015 11:34 AM, Michael Natterer wrote:

So now we have some new code, in the playground, so that it will be off by default in a stable release.

A somewhat off-topic question:

I have the n-point deformation and handle transform checked in the playground and I restarted GIMP. But I can't find either of them anywhere in the GIMP menu.

How do you access the playground tools and options?

They are not in the menu because it requires quite some hacking to make menu entries configurable like that (significant amounts of weird code, not worth the effort for experiments).

Playground tools are only available from the toolbox.

Regards, Mitch

On 03/08/2015 06:53 PM, Michael Natterer wrote:

They are not in the menu because it requires quite some hacking to make menu entries configurable like that (significant amounts of weird code, not worth the effort for experiments).

Playground tools are only available from the toolbox.

Mitch, thanks! I found the toolbox icons.

As was mentioned on IRC, the n-point deformation tool is CPU-intensive even for a very small image. I was testing on an 800px by 600px image.

If the code executed faster, it seems like it would be extremely useful for things like controlled modification of facial features and for smoothly blending together portions of several frames of the same subject, when the frames don't match up well enough for automated blending (hugin). But my old computer simply isn't fast enough to do much testing.

Elle

On Tue, Mar 10, 2015 at 12:46 AM, Elle Stone wrote:

On 03/08/2015 06:53 PM, Michael Natterer wrote:

They are not in the menu because it requires quite some hacking to make menu entries configurable like that (significant amounts of weird code, not worth the effort for experiments).

Playground tools are only available from the toolbox.

Mitch, thanks! I found the toolbox icons.

As was mentioned on IRC, the n-point deformation tool is CPU-intensive even for a very small image. I was testing on an 800px by 600px image.

If the code executed faster, it seems like it would be extremely useful for things like controlled modification of facial features and for smoothly blending together portions of several frames of the same subject, when the frames don't match up well enough for automated blending (hugin). But my old computer simply isn't fast enough to do much testing.

It is perhaps worth noting that the tool is a lot faster on 8-bit image data, at least it was when I tested it.

Mikael Magnusson

On 03/10/2015 01:46 AM, Mikael Magnusson wrote:

If the code executed faster, it seems like it would be extremely useful for things like controlled modification of facial features and for smoothly blending together portions of several frames of the same subject, when the frames don't match up well enough for automated blending (hugin). But my old computer simply isn't fast enough to do much testing.

It is perhaps worth noting that the tool is a lot faster on 8-bit image data, at least it was when I tested it.

I figured out that you have to hit Return before the CPU will quit churning away doing nothing, after you stop moving control points around. Maybe that would be obvious to most people . . .

Elle

On Mar 11, 2015, at 3:30 PM, Alexandre Prokoudine wrote:

vector layers

Wow - what a wonderful idea!

Works just like text layers!

- - - “Dream on,” s/he explained.