[warning, long mail ahead]

Ellen Reitmayr ([EMAIL PROTECTED]) wrote:
> > In the Edit mode you can *add* points on a segment. You can *add* a
> > segment to the path when a single endpoint is selected and you click on
> > the other one (this btw. is the same as connecting start- and endpoints,
> > which you wrongly describe in the report as "Design mode + CTRL", when
> > looking at the tool options you'll realize that CTRL is a shortcut for
> > switching into the Edit mode)
> 
> Hm, here again, the shortcuts are not clearly communicated. As the tool
> is quite complex, it is not so easy to understand the whole
> functionality of a single shortcut (-> even the GIMP 1.2 user who
> attended some workshops thought that CTRL would connect start and end
> points only).

Visually pressing down CTRL or ALT is immediately visible in the tool
options: The mode switch will switch accordingly. What else would you
suggest to communicate this more clearly?

> > [...]Thats why it is not really an option to rename the Edit mode to "Remove"
> > mode, that simply isn't the reality.
> 
> Yes, I see. 
> But I had one more look on the path tool as implemented in GIMP 1.2.
> There, you had four modes:
> - New Point
> - Add Point
> - Remove Point
> - Edit Point
> 
> Is it so, that 'new point' and 'edit point' are 'Design' now, while 'add
> point' and 'remove point' are 'Edit'? 

Basically it is impossible to really compare the path tool in 1.2 and
the path tool in 2.0. I have rewritten the Path tool from scratch,
removing arbitrary limitations and implementing some new ideas.

(Just out of curiosity: Did you ever try to use the 1.2 path tool? I
always found it counter-intuitive: it consistently destroyed my existing
path, even after years of gimp usage..., the need to move to the buttons
to switch the mode was constantly annoying)

> I wonder if it wouldn't be easier to re-implement those modes (a bit
> modified): Currently, the 'remove' function is not accessible from the
> Design-Mode, as the keyboard shortcut does not work. Even in the edit
> mode is does not become clear, how to delete a point (status message not
> clear as it only says 'try shift'). 
> I would propose the following modes (each accessible via keyboard
> shortcuts):
> 
> - Design (== new point + Edit Point; default)
> - Add (== add point or segment; CTRL)
> - Remove (== delete point or segment; SHIFT)
> - Move All (ALT)
> 
> What do you think?

In this way it is impossible, because SHIFT is used as a modifier in all
three currently existing modes. In Design mode you can a) use SHIFT to
select multiple points on a path and move them together, b) when dragging
control handles SHIFT makes the opposite handle move symmetrically and
c) pressing SHIFT while creating a new node forces the creation of a new
component, not connected to the previous.

The Edit mode uses SHIFT for the add vs. delete thingie as discussed
earlier and the Move mode uses Shift to move all components of a path
simultaneously.

Given the prerequisite, that the whole tool should be usable without
having to move the mouse back and forth to a buttonbar (jimmac already
wrote about this) and the need for a modifier (SHIFT) we have two
modifiers left, which lead to the three modes of the existing tool. In
theory we could use CTRL+ALT for a fourth mode, but this would require
the user of the tool to be quite a finger acrobat and is probably not
really a good idea.

> > : Provide a hint in the status bar 'To connect start and end point,
> > : press CTRL'. 
> > 
> > When exactly should this displayed? Currently the Statusbar gives hints
> > what will happen when the user clicks now. It will give the hint "click
> > to connect the anchor with the selected endpoint", when the user is in
> > Edit mode and hovers over an anchor.
> 
> the problem is that this is not clear in 'Design' mode. Maybe it is
> possible to display this message in Design mode only for the start and
> the end point, but not for comprised points?

There are two problems: first: the room in the statusbar is quite
limited, there is no way to describe two different actions
simultaneously, I tried it, but had to settle to the "(try SHIFT)"
encouragement to enable the user to discover more functionality.

The other problem is quite profane: The help text depends heavily on the
currently selected internal function (there are 16 of these internal
functions), and which of these internal functions is selected depends
(in decreasing priority) 
   * on the currently active mode,
   * the item the cursor is positioned over,
   * the SHIFT-modifier state and
   * some extra conditions.

If a path is closeable depends on an extra condition (only one endpoint
currently selected *and* hovering over a different endpoint). Now
assuming I had determined that I can click-drag the anchor the pointer
is hovering over I'd have to also check if it would be possible to close
a path: When you look at the priorities above you'll notice that this is
a completely different path of descisions.
It might sound like an excuse, but I simply cannot put in the logic to
not only determine the current function, but also the logic to determine
the current function if I were in the other modes. It is already a
highly complex logic, and everything else would most probably make my
brain explode.

if you're curious you're welcome to look at gimp_vector_tool_oper_update
in app/tools/gimpvectortool.c, where the logic to select the internal
function is implemented.


I hope you understand that I am not trying to generally avoid changes to
the tool or even make you go away. The point is, that this tool is a
beast of complexity and I literally spent weeks to figure out how this
should behave in a sane way.

I admit that I did not focus on the newbie who just did his first gimp
start. I intentionally focussed on people who use the tool on a regular
basis and are willing to invest some time to study it. I tried hard to
find some compromises to make the tool more discoverable and this is
what I came up with, and - sorry - I don't see how your proposed
solutions will help here, they maybe would make it easier to close a
path, but they also would make the rest a lot more inconsistent.

So, currently my answer to these problems is: Read the docs, although I
admit that the definitive path documentation is not yet written (there
are some nice introductory tutorials written by scizzo that should give
an introduction to the basic features), I guess I should put up a page
describing the path tool in detail. 

How do we proceed from here? Actually I am not sure. I can introduce a
fourth mode in the tool but a major blocker is a mapping to the
modifiers here:

We have to assign these functions:
 - add anchor
 - add anchor, starting a new stroke
 - move anchors
 - move multiple anchors
 - move handles
 - move handles symmetrically
 - move curve
 - move curve symmetrically
 - drag handles out of an anchor
 - delete a handle (i.e. move it back to the anchor)
 - add an anchor on a segment
 - delete an anchor
 - connect two components
 - delete a segment (i.e. creating two open strokes)
 - move a stroke
 - move the path

You can click on a) anchors, b) handles, c) segments and d) canvas.
Assuming we want four modes (No modifer, SHIFT, CTRL, ALT), we have
4 * 4 = 16 possible combinations, which - from a naive point of view -
would match the 16 functions above, but it is pretty clear that some of
these functions are bound to specific elements and so this is bound to
fail. Thats why I've gone for three modes (No modifier, CTRL, ALT) plus
a modifier (SHIFT), giving me the opportunity to juggle a bit more: Now
I have 3 * 2 * 4 = 24 slots to assign the functions mentioned above. The
result of this is currently visible in the GIMP.

So, if you propose to add a fourth mode please also propose a way to get
out of the dilemma explained above. I hope you can understand, why I am
a bit skeptical about your suggestion.

Huh, complicated stuff...  :-)

Bye,
        Simon
-- 
              [EMAIL PROTECTED]              http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to