Home » Eclipse Projects » GEF » Branched Connections - possible Contribution
| Branched Connections - possible Contribution [message #95157] |
Wed, 24 September 2003 09:19  |
Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
In my recent exploits with branched connections, I've tried the following.
1) Create connections between the same endpoints and modify the routing to
make it look as if it were a single branched connection. - ultimately not a
very good idea. Far too many hacks required to get this working &
fundamentally stupid.
2) Attach connections to already existing connections. I tried this today,
it seemed to work fine. But, the major problem here is I actually need all
the connections to behave like a single connection.
Take this example.
If I attach a connection to an already existing connection I get a secondary
connection. I use a very simple Connection anchor which just returns the
closest point of the PolyLineConnection figure to which we are connecting
(closest to the target point - the argument to getLocation()). [Randy, all I
had to do here was extend AbstractConnectionAnchor and implement
getLocation... the secondary connection remains attached to the closest
point... even when the primamary connection is reconnected and re-routed -
so far, I haven't added any more listeners / methods]
A connection now could be attached to the secondary connection, leading to a
ternary connection. A branching point is found from the secondary
connection. But conceptually, the primary and secondary connection are the
same... and it is possible that a better brancing point (a closer point)
could be found on the primary connection. So even tho I initiated the
connection from the secondary connection (and it's editpart received the
request) I would have to somehow get the new connection to connect to the
primary connection instead of the secondary. And all this could change when
the EditParts to which the Primary connections are connected to are dragged
around. BTW, Secondary/ ternary /... connections usually have one endpoint
on a connection and the other on a normal EditPart, like a rectangle for
instance.
Finally (and most IMPORTANTLY), all these connections are seperately
selectable and they have different model objects. But I require it to
correspond to just a single model (one model several EditParts is possible,
but I don't think this is the right way to go). I don't want them to be
separately selectable. The above approaches have further complications when
the primary connection is deleted. (One of the secondary connections
attached to it will have to attach itself to the EditPart that the Primary
was connected to.. and all the other secondary connections will have to
attach themselves to this one)
After 3 days of painful coding, recoding and hacking, I've come to the
conclusion that the cleanest solution would be to have a connection with
multiple endpoints. I'm sure this might not be the simplest. solution, but I
don't see what else can be done. Just thinking about this frightens me; the
source and target point concept might work anymore and God knows what
architectural changes might be require to get this working.
I will contribute this to GEF when finished - A MultiEndPoint connection;
but I'm going to need some serious help with it. Right now I have zeroIdea
where to start.
Do you have any alternative suggestions ?
I'm attaching a picture of a sample connection. All the lines you see in red
is actually a single connection with multiple endpoints. This is what I
need.
Hope you had the patience to read till here,
Thanks for the time,
Brian.
Attachment: routing2.jpg
(Size: 10.54KB, Downloaded 108 times)
|
|
|
| Re: Branched Connections - possible Contribution [message #95174 is a reply to message #95157] |
Wed, 24 September 2003 09:51  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I thought 1) was the best idea. You should allow each head to be
individually selectable. This way the user can delete one head without
deleting the other 5. A ConnectionRouter could handle routing multiple
connections at once.
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:bks4s1$j2p$1@eclipse.org...
> In my recent exploits with branched connections, I've tried the following.
>
> 1) Create connections between the same endpoints and modify the routing
to
> make it look as if it were a single branched connection. - ultimately not
a
> very good idea. Far too many hacks required to get this working &
> fundamentally stupid.
>
> 2) Attach connections to already existing connections. I tried this today,
> it seemed to work fine. But, the major problem here is I actually need all
> the connections to behave like a single connection.
>
> Take this example.
> If I attach a connection to an already existing connection I get a
secondary
> connection. I use a very simple Connection anchor which just returns the
> closest point of the PolyLineConnection figure to which we are connecting
> (closest to the target point - the argument to getLocation()). [Randy, all
I
> had to do here was extend AbstractConnectionAnchor and implement
> getLocation... the secondary connection remains attached to the closest
> point... even when the primamary connection is reconnected and re-routed -
> so far, I haven't added any more listeners / methods]
>
> A connection now could be attached to the secondary connection, leading to
a
> ternary connection. A branching point is found from the secondary
> connection. But conceptually, the primary and secondary connection are the
> same... and it is possible that a better brancing point (a closer point)
> could be found on the primary connection. So even tho I initiated the
> connection from the secondary connection (and it's editpart received the
> request) I would have to somehow get the new connection to connect to the
> primary connection instead of the secondary. And all this could change
when
> the EditParts to which the Primary connections are connected to are
dragged
> around. BTW, Secondary/ ternary /... connections usually have one endpoint
> on a connection and the other on a normal EditPart, like a rectangle for
> instance.
>
> Finally (and most IMPORTANTLY), all these connections are seperately
> selectable and they have different model objects. But I require it to
> correspond to just a single model (one model several EditParts is
possible,
> but I don't think this is the right way to go). I don't want them to be
> separately selectable. The above approaches have further complications
when
> the primary connection is deleted. (One of the secondary connections
> attached to it will have to attach itself to the EditPart that the Primary
> was connected to.. and all the other secondary connections will have to
> attach themselves to this one)
>
> After 3 days of painful coding, recoding and hacking, I've come to the
> conclusion that the cleanest solution would be to have a connection with
> multiple endpoints. I'm sure this might not be the simplest. solution, but
I
> don't see what else can be done. Just thinking about this frightens me;
the
> source and target point concept might work anymore and God knows what
> architectural changes might be require to get this working.
>
> I will contribute this to GEF when finished - A MultiEndPoint connection;
> but I'm going to need some serious help with it. Right now I have zeroIdea
> where to start.
> Do you have any alternative suggestions ?
>
> I'm attaching a picture of a sample connection. All the lines you see in
red
> is actually a single connection with multiple endpoints. This is what I
> need.
>
> Hope you had the patience to read till here,
> Thanks for the time,
> Brian.
>
>
>
|
|
|
| Re: Branched Connections - possible Contribution [message #95220 is a reply to message #95174] |
Wed, 24 September 2003 11:42 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
"Randy Hudson" <none@us.ibm.com> wrote in message
news:bks7d9$m5p$1@eclipse.org...
> I thought 1) was the best idea. You should allow each head to be
> individually selectable. This way the user can delete one head without
> deleting the other 5.
I just thought I'd remind you that I'm using connections with selectable
endpoints, .. the endpoints are children of the connection and they are
selectable separately from the connection itself. I would be able to treat
the deletion of the head of a connection specially in this case ?
A ConnectionRouter could handle routing multiple
> connections at once.
>
I also have the lanepoints issue which I've solved for a single connection.
If a connection crosses a lane, a lane point is created which allows me to
move the connection along the vertical axis.
When multiple connectons exist and cross the lane, each of them would have
separate lane points (handles). Movement of a lane point would cause only
one of the connections to move, leaving the other connections in the same
place. I would have to somehow make sure that the dragging of one of the
handles causes appropriate handles on the other secondary connections to
drag as well ?
In line with solution 1, which I was persuing today, this morning I also
tried implementing the drag tracker in such a way as to select all the
connections connected to a single edit part. I had the following issues.
1) I used viewer.select to select the connection. .. but that cancels the
previous selection and selects the newly specified editPart. How do I select
multiple edit parts at once .
2) In logic, I tried using the shift key to select more than one connection
at the same time. Both got selected. Good. But when I tried to reconnect
them, only the one whose endpoint I dragged began to reconnect, the other
selected connection refused to reconnect, even though it remained selected.
The problem of dragging and reconnecting multiple connections (those
connected to the same editpart) at the same time, which is required in
option proposed solution 1. goes much beyond simply selecting multiple
connections - could you tell me how I should modify the drag tracker for
this ?
Manipulating the routing algo to cause the multiple connections to overlap
is not too difficult, I agree, but then I face the above mentioned problems.
1) Manipulating the lanepoints of all the connections (which are supposed to
be the same connection) at the same time.
2) Reconnecting all connections connected to a single edit part at the same
time.
3) All the connections have to have a common set of properties.. that have
to have the same model object.
I'm oscillating between all the ideas now and I would really appreciate
further direction.
Thanks for your time,
Brian.
|
|
|
| Re: Branched Connections - possible Contribution [message #95276 is a reply to message #95220] |
Wed, 24 September 2003 16:17 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
It sounds like you understand the technical issues, and since you've spent
several days in code, you're opinion is probably better than mine. I was
just trying to represent the user. Your way of selecting the connection
endpoints to allow delete sounds equivalent to selecting each segment.
-randy
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:bksd7h$tbo$1@eclipse.org...
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:bks7d9$m5p$1@eclipse.org...
> > I thought 1) was the best idea. You should allow each head to be
> > individually selectable. This way the user can delete one head without
> > deleting the other 5.
>
> I just thought I'd remind you that I'm using connections with selectable
> endpoints, .. the endpoints are children of the connection and they are
> selectable separately from the connection itself. I would be able to treat
> the deletion of the head of a connection specially in this case ?
>
> A ConnectionRouter could handle routing multiple
> > connections at once.
> >
>
> I also have the lanepoints issue which I've solved for a single
connection.
>
> If a connection crosses a lane, a lane point is created which allows me to
> move the connection along the vertical axis.
>
> When multiple connectons exist and cross the lane, each of them would have
> separate lane points (handles). Movement of a lane point would cause only
> one of the connections to move, leaving the other connections in the same
> place. I would have to somehow make sure that the dragging of one of the
> handles causes appropriate handles on the other secondary connections to
> drag as well ?
>
> In line with solution 1, which I was persuing today, this morning I also
> tried implementing the drag tracker in such a way as to select all the
> connections connected to a single edit part. I had the following issues.
> 1) I used viewer.select to select the connection. .. but that cancels the
> previous selection and selects the newly specified editPart. How do I
select
> multiple edit parts at once .
>
> 2) In logic, I tried using the shift key to select more than one
connection
> at the same time. Both got selected. Good. But when I tried to reconnect
> them, only the one whose endpoint I dragged began to reconnect, the other
> selected connection refused to reconnect, even though it remained
selected.
>
> The problem of dragging and reconnecting multiple connections (those
> connected to the same editpart) at the same time, which is required in
> option proposed solution 1. goes much beyond simply selecting multiple
> connections - could you tell me how I should modify the drag tracker for
> this ?
>
> Manipulating the routing algo to cause the multiple connections to overlap
> is not too difficult, I agree, but then I face the above mentioned
problems.
> 1) Manipulating the lanepoints of all the connections (which are supposed
to
> be the same connection) at the same time.
> 2) Reconnecting all connections connected to a single edit part at the
same
> time.
> 3) All the connections have to have a common set of properties.. that have
> to have the same model object.
>
> I'm oscillating between all the ideas now and I would really appreciate
> further direction.
>
> Thanks for your time,
> Brian.
>
>
|
|
|
| Re: Branched Connections - possible Contribution [message #95464 is a reply to message #95220] |
Thu, 25 September 2003 11:51 |
| Eclipse User |
|
|
|
Originally posted by: brian.fernandes.codito.com
I've decided to go for solution 2. .. Connections connected to connections.
Sheesh; this is trying.
Is there any way in which I can make several EditParts correspond to a
single Model ? All the connections which are connected to each other should
actually have the same data in their model objects.. how do I do this ?
Thanks,
Brian.
"Brian Fernandes" <brian.fernandes@codito.com> wrote in message
news:bksd7h$tbo$1@eclipse.org...
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:bks7d9$m5p$1@eclipse.org...
> > I thought 1) was the best idea. You should allow each head to be
> > individually selectable. This way the user can delete one head without
> > deleting the other 5.
>
> I just thought I'd remind you that I'm using connections with selectable
> endpoints, .. the endpoints are children of the connection and they are
> selectable separately from the connection itself. I would be able to treat
> the deletion of the head of a connection specially in this case ?
>
> A ConnectionRouter could handle routing multiple
> > connections at once.
> >
>
> I also have the lanepoints issue which I've solved for a single
connection.
>
> If a connection crosses a lane, a lane point is created which allows me to
> move the connection along the vertical axis.
>
> When multiple connectons exist and cross the lane, each of them would have
> separate lane points (handles). Movement of a lane point would cause only
> one of the connections to move, leaving the other connections in the same
> place. I would have to somehow make sure that the dragging of one of the
> handles causes appropriate handles on the other secondary connections to
> drag as well ?
>
> In line with solution 1, which I was persuing today, this morning I also
> tried implementing the drag tracker in such a way as to select all the
> connections connected to a single edit part. I had the following issues.
> 1) I used viewer.select to select the connection. .. but that cancels the
> previous selection and selects the newly specified editPart. How do I
select
> multiple edit parts at once .
>
> 2) In logic, I tried using the shift key to select more than one
connection
> at the same time. Both got selected. Good. But when I tried to reconnect
> them, only the one whose endpoint I dragged began to reconnect, the other
> selected connection refused to reconnect, even though it remained
selected.
>
> The problem of dragging and reconnecting multiple connections (those
> connected to the same editpart) at the same time, which is required in
> option proposed solution 1. goes much beyond simply selecting multiple
> connections - could you tell me how I should modify the drag tracker for
> this ?
>
> Manipulating the routing algo to cause the multiple connections to overlap
> is not too difficult, I agree, but then I face the above mentioned
problems.
> 1) Manipulating the lanepoints of all the connections (which are supposed
to
> be the same connection) at the same time.
> 2) Reconnecting all connections connected to a single edit part at the
same
> time.
> 3) All the connections have to have a common set of properties.. that have
> to have the same model object.
>
> I'm oscillating between all the ideas now and I would really appreciate
> further direction.
>
> Thanks for your time,
> Brian.
>
>
|
|
|
Goto Forum:
Current Time: Wed Jul 16 00:19:03 EDT 2025
Powered by FUDForum. Page generated in 0.27265 seconds |
Home