Issue 70373

Created attachment 39707 [details]
description how connecting paths should work

Reassigned.

Created attachment 39722 [details]
improved description

Regina: an excellent Issue and spec, nice! BTW, should Issue 14154 now be marked
as depending on this Issue?

Cheers,
Andrew

I found no description how the command "connect" should work and I don't know,
if it is possible to repair it. But if this new way (or something like this) is
implemented, then - I think - the old command is no longer needed. If you call
that "depending", then it should be marked.

Excellent proposal!

I would like to suggest a change to try and make the connect operation as simple
as possible.

If the user selects one head and one tail, then the direction of the resulting
line after connecting is unambiguous.

If the user wishes to join head-to-head or tail-to-tail, extra steps are
required to select and reverse one line. This is likely to be a difficult task:
many users are not aware that lines have a direction; likewise, they will not
anticipate the need to reverse one line. They may be frustrated that the connect
operation is not available. Once all those pre-requisites are met, it requires a
mental exercise to determine which line has to be reversed to produce the
desired result.

In many cases, the direction of the line is irrelevant to the user, so that all
this effort will be pure distraction from the task at hand.

So I propose that when the user has selected two heads or two tails, that Draw
should choose the resulting direction based on the order the points are selected
in, or if the points were selected simultaneously, the order that the two lines
were created in.

This would be equivalent to the steps in the spec, where the direction of one
line must be reversed by the user before the connection operation is allowed,
except that Draw would apply the reversing operation automatically.

If this is not practical, e.g. because there is no support for determining which
point is selected first, then perhaps the spec could be written so as to be
implemented in steps, with this behavior as the longer-term goal.

A separate comment on the proposal.

Based on my experience, I believe that most users will expect that a connect
operation and a "split curve" operation are reciprocal, i.e. that one operation
"undoes" the other. Currently the "split curve" button operates on any number of
points from one curve, including one, and cannot join or connect points.

Could the proposed "connect" operation and the existing "split" operation either
be coordinated in some way to support the naive user's mental model and
expectations, or be distinguished somehow to make it clear that they are
entirely different operations.

This could also avoid the need to add more function buttons to an already
complex toolbar.