Re: [Gimp-developer] Move tool

Alexandre wrote:

Recently someone pinged me (again) about a certain inconsistency that
I've seen affecting a considerable amount of users: that the Move tool doesn't move contents of selections.

Frankly, I don't understand the logic behind this myself.

Selection tools are for selecting. Move tool is for moving. But we
made moving contents of selections part of selection tools for some
reason, and we made this as non-obvious as possible.

It looks like we assume that users actually read whatever is displayed
in the status bar and do try various combinations of Shift, Alt, and
Ctrl to see what happens. Clearly, this isn't working: I've seen users
trying the (subjectively) logical way to use a selection tool to
select, then switch to the move tool to move, fail, and give up.

What does the usability department think of this? :)

yes, first one gets the basics right:

Selection tools are for selecting. Move tool is for moving.

simple enough and a core convention in GIMP is that
that avery operation (move in this case) is masked
by the current selection.

that is the basis to start from.

on top of that it makes sense for a tool for ‘intense work’
like GIMP to build in some power cross-pollination
for some straightforward operations:

- so it is right that as an extra power mode
 the move tool can move the selection (the mask, not the content).

- less logical, but still possible: as an extra power mode
 the selection tool can move the selected content.
 (less logical, because a further set of basic operations
 can be assembled that could get the same rights; e.g.
 immediately the question comes up why an extra power mode for
 resize is not there too)

Michael Grosberg wrote:

Another related issue though is moving a selection outside (partly or fully) the layer boundary. currently 
the selection content simply disappears. 
It would be nice if this somehow enlarged the boundary.

with the current system of explicit layer boundaries, it is
50–50% whether the layer boundary should clip the content or
be extended itself (just a competition of use cases).

when we move to system of automatic layer boundaries (something
I have encouraged for a long time), aka simply no layer boundaries,
then the issue is solved by itself (the canvas size would clip
material when exporting, however).


        founder + principal interaction architect
            man + machine interface works on interaction architecture

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