Issue 70373 - New way for connecting curves and polylines
Summary: New way for connecting curves and polylines
Alias: None
Product: Draw
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0.4
Hardware: PC Windows XP
: P3 Trivial with 4 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-10-13 01:01 UTC by Regina Henschel
Modified: 2013-02-07 22:41 UTC (History)
2 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---

description how connecting paths should work (131.11 KB, application/vnd.oasis.opendocument.text)
2006-10-13 01:02 UTC, Regina Henschel
no flags Details
improved description (133.59 KB, application/vnd.oasis.opendocument.text)
2006-10-13 09:22 UTC, Regina Henschel
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2006-10-13 01:01:06 UTC
The command "connect" in the menu modify works worse. But I think it cannot be
improved, because the whole idea is wrong. Therefore I suggest a new way to
connect two paths, which is in some way similar to the way in CorelDRAW and
Inkscape. I will attach a document, which tells in detail how I think it should
Comment 1 Regina Henschel 2006-10-13 01:02:12 UTC
Created attachment 39707 [details]
description how connecting paths should work
Comment 2 wolframgarten 2006-10-13 07:47:41 UTC
Comment 3 Regina Henschel 2006-10-13 09:22:47 UTC
Created attachment 39722 [details]
improved description
Comment 4 ace_dent 2006-10-18 15:44:31 UTC
Regina: an excellent Issue and spec, nice! BTW, should Issue 14154 now be marked
as depending on this Issue?

Comment 5 Regina Henschel 2006-10-18 16:32:09 UTC
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.
Comment 6 Joe Smith 2007-02-06 22:51:14 UTC
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.
Comment 7 Joe Smith 2007-02-06 23:05:39 UTC
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.