Home » Eclipse Projects » GEF » Connection clipping current state of the art
| Connection clipping current state of the art [message #150418] |
Fri, 10 September 2004 02:32  |
Eclipse User |
|
|
|
Originally posted by: vladimir.bogus.com
Hello,
What is the preferred way of dealing with the default absense of the
connection's clipping behaviour (The connection node clipping does not
affect the clipping of the connection itself, and, for example, if the nodes
are clipped off and are not visible, the connection will still be visible).
One suggestion was to set the connection's parent to the nodes' container
Figure. This indeed adds clipping to the connection (with a seemingly minor
side effect of NullPointerException thrown at
org.eclipse.gef.editpolicies.BendpointEditPolicy.createHandl esForUserBendpoi
nts(BendpointEditPolicy.java:75 on selecting a connection. What is the
preferred way of dealing with this exception?).
I did not find any standard and general solutions to a more general problem
of the connections' nodes belonging to different containers and so any
suggestions would be appreciated in this regard.
Vladimir
|
|
| |
| Re: Connection clipping current state of the art [message #150658 is a reply to message #150583] |
Mon, 13 September 2004 00:28  |
| Eclipse User |
|
|
|
Originally posted by: vgusev.graphlogic.com
This seems to be the beginning of dealing with this issue and has side
effects listed in the original post. As a general solution, I am think about
implementing a special connection layer in the Figure that is the
bottom-most on the ancestor chain? When the user draws the connection it
paints on the standard connection layer so it is not clipped at all. After
the user finishes drawing the connection, it is moved to this special layer
belonging to the bottom-most ancestor of the connected nodes, which should
allow proper clipping. What do you think of this solution design-wise and in
terms of possible side effects? Thanks.
Vladimir
"Pratik Shah" <ppshah@us.ibm.com> wrote in message
news:chvglr$hos$1@eclipse.org...
> From one of Randy Hudson's previous posts:
>
> If you want to change the figure which parents the
> connection to be some layer in your container, see
> AbstractConnectionEditPart#activateFigure(). This determines the
> connection's parent, and therefore its clipping.
>
> "Vladimir" <vladimir@bogus.com> wrote in message
> news:chr3h2$ncc$1@eclipse.org...
> > Hello,
> >
> > What is the preferred way of dealing with the default absense of the
> > connection's clipping behaviour (The connection node clipping does not
> > affect the clipping of the connection itself, and, for example, if the
> nodes
> > are clipped off and are not visible, the connection will still be
> visible).
> >
> > One suggestion was to set the connection's parent to the nodes'
container
> > Figure. This indeed adds clipping to the connection (with a seemingly
> minor
> > side effect of NullPointerException thrown at
> >
>
org.eclipse.gef.editpolicies.BendpointEditPolicy.createHandl esForUserBendpoi
> > nts(BendpointEditPolicy.java:75 on selecting a connection. What is the
> > preferred way of dealing with this exception?).
> >
> > I did not find any standard and general solutions to a more general
> problem
> > of the connections' nodes belonging to different containers and so any
> > suggestions would be appreciated in this regard.
> >
> > Vladimir
> >
> >
>
>
|
|
|
| Re: Connection clipping current state of the art [message #150735 is a reply to message #150658] |
Mon, 13 September 2004 18:07 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You could implement the "common ancestor" clipping at the connection router.
Perform the actual clipping on the pointlist itself. This also ensures that
clipping only happens once and at exaclty the right time. Also, hit-testing
will work properly because there is no magic.
I didn't understand the proposed solution below. Feel free to elaborate
"Bob" <vgusev@graphlogic.com> wrote in message
news:ci2oi3$rmi$1@eclipse.org...
> This seems to be the beginning of dealing with this issue and has side
> effects listed in the original post. As a general solution, I am think
about
> implementing a special connection layer in the Figure that is the
> bottom-most on the ancestor chain? When the user draws the connection it
> paints on the standard connection layer so it is not clipped at all. After
> the user finishes drawing the connection, it is moved to this special
layer
> belonging to the bottom-most ancestor of the connected nodes, which should
> allow proper clipping. What do you think of this solution design-wise and
in
> terms of possible side effects? Thanks.
>
> Vladimir
>
> "Pratik Shah" <ppshah@us.ibm.com> wrote in message
> news:chvglr$hos$1@eclipse.org...
> > From one of Randy Hudson's previous posts:
> >
> > If you want to change the figure which parents the
> > connection to be some layer in your container, see
> > AbstractConnectionEditPart#activateFigure(). This determines the
> > connection's parent, and therefore its clipping.
> >
> > "Vladimir" <vladimir@bogus.com> wrote in message
> > news:chr3h2$ncc$1@eclipse.org...
> > > Hello,
> > >
> > > What is the preferred way of dealing with the default absense of the
> > > connection's clipping behaviour (The connection node clipping does not
> > > affect the clipping of the connection itself, and, for example, if the
> > nodes
> > > are clipped off and are not visible, the connection will still be
> > visible).
> > >
> > > One suggestion was to set the connection's parent to the nodes'
> container
> > > Figure. This indeed adds clipping to the connection (with a seemingly
> > minor
> > > side effect of NullPointerException thrown at
> > >
> >
>
org.eclipse.gef.editpolicies.BendpointEditPolicy.createHandl esForUserBendpoi
> > > nts(BendpointEditPolicy.java:75 on selecting a connection. What is the
> > > preferred way of dealing with this exception?).
> > >
> > > I did not find any standard and general solutions to a more general
> > problem
> > > of the connections' nodes belonging to different containers and so any
> > > suggestions would be appreciated in this regard.
> > >
> > > Vladimir
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Connection clipping current state of the art [message #150748 is a reply to message #150735] |
Mon, 13 September 2004 20:56 |
| Eclipse User |
|
|
|
Originally posted by: vladimir.bogus.com
I am proposing to break this use case into two consecutive steps:
1. User selected a node with the connection tool and drags it towards a
second node. In this state, there should be no clipping. To achieve this,
the connection should be drawn on the standard connection layer - no
different compared to how this currently works in gef, and cannot be done
differently since the second node is not known at this point.
2. After the user finished creating connection, in general case, the
connection will have to be clipped. The clipping is dependent upon all of
the successors of the common ancestor. I think that if the connection is
drawn in the layer associated with the common ancestor, the correct clipping
will happen automatically. To achieve this I am proposing to create a new
connection layer in the common ancestor and move the connection created on
step 1 to this new connection layer.
Is step 2 above equivalent to what you call "implementing common ancestor"?
I cannot say, since I don't understand how to do "clipping at the connection
router". Please provide more details. Also, shouldn't this behaviour be the
one of the gef?
Thanks.
Vladimir
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ci4ndg$2js$1@eclipse.org...
> You could implement the "common ancestor" clipping at the connection
router.
> Perform the actual clipping on the pointlist itself. This also ensures
that
> clipping only happens once and at exaclty the right time. Also,
hit-testing
> will work properly because there is no magic.
>
> I didn't understand the proposed solution below. Feel free to elaborate
>
> "Bob" <vgusev@graphlogic.com> wrote in message
> news:ci2oi3$rmi$1@eclipse.org...
> > This seems to be the beginning of dealing with this issue and has side
> > effects listed in the original post. As a general solution, I am think
> about
> > implementing a special connection layer in the Figure that is the
> > bottom-most on the ancestor chain? When the user draws the connection it
> > paints on the standard connection layer so it is not clipped at all.
After
> > the user finishes drawing the connection, it is moved to this special
> layer
> > belonging to the bottom-most ancestor of the connected nodes, which
should
> > allow proper clipping. What do you think of this solution design-wise
and
> in
> > terms of possible side effects? Thanks.
> >
> > Vladimir
> >
> > "Pratik Shah" <ppshah@us.ibm.com> wrote in message
> > news:chvglr$hos$1@eclipse.org...
> > > From one of Randy Hudson's previous posts:
> > >
> > > If you want to change the figure which parents the
> > > connection to be some layer in your container, see
> > > AbstractConnectionEditPart#activateFigure(). This determines the
> > > connection's parent, and therefore its clipping.
> > >
> > > "Vladimir" <vladimir@bogus.com> wrote in message
> > > news:chr3h2$ncc$1@eclipse.org...
> > > > Hello,
> > > >
> > > > What is the preferred way of dealing with the default absense of the
> > > > connection's clipping behaviour (The connection node clipping does
not
> > > > affect the clipping of the connection itself, and, for example, if
the
> > > nodes
> > > > are clipped off and are not visible, the connection will still be
> > > visible).
> > > >
> > > > One suggestion was to set the connection's parent to the nodes'
> > container
> > > > Figure. This indeed adds clipping to the connection (with a
seemingly
> > > minor
> > > > side effect of NullPointerException thrown at
> > > >
> > >
> >
>
org.eclipse.gef.editpolicies.BendpointEditPolicy.createHandl esForUserBendpoi
> > > > nts(BendpointEditPolicy.java:75 on selecting a connection. What is
the
> > > > preferred way of dealing with this exception?).
> > > >
> > > > I did not find any standard and general solutions to a more general
> > > problem
> > > > of the connections' nodes belonging to different containers and so
any
> > > > suggestions would be appreciated in this regard.
> > > >
> > > > Vladimir
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
|
|
| Re: Connection clipping current state of the art [message #150839 is a reply to message #150748] |
Tue, 14 September 2004 18:47 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Vladimir" <vladimir@bogus.com> wrote in message
news:ci519p$l42$1@eclipse.org...
> I am proposing to break this use case into two consecutive steps:
>
> 1. User selected a node with the connection tool and drags it towards a
> second node. In this state, there should be no clipping. To achieve this,
> the connection should be drawn on the standard connection layer - no
> different compared to how this currently works in gef, and cannot be done
> differently since the second node is not known at this point.
>
> 2. After the user finished creating connection, in general case, the
> connection will have to be clipped. The clipping is dependent upon all of
> the successors of the common ancestor. I think that if the connection is
> drawn in the layer associated with the common ancestor, the correct
clipping
> will happen automatically. To achieve this I am proposing to create a new
> connection layer in the common ancestor and move the connection created on
> step 1 to this new connection layer.
>
> Is step 2 above equivalent to what you call "implementing common
ancestor"?
> I cannot say, since I don't understand how to do "clipping at the
connection
Take a PointList and a Rectangle. Trim the beginning and end of the
pointlist until it lies within the rectangle, which may involve removing
points or modifying points.
> router". Please provide more details. Also, shouldn't this behaviour be
the
> one of the gef?
Nope :-) At least half of the GEF applications do not even have nestable
containers. They are just icons and lines.
|
|
|
| Re: Connection clipping current state of the art [message #150859 is a reply to message #150839] |
Tue, 14 September 2004 21:40 |
| Eclipse User |
|
|
|
Originally posted by: vladimir.bogus.com
What do you think about switching connection layers?
Thanks.
Vladimir
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ci7e4a$ima$1@eclipse.org...
>
> "Vladimir" <vladimir@bogus.com> wrote in message
> news:ci519p$l42$1@eclipse.org...
> > I am proposing to break this use case into two consecutive steps:
> >
> > 1. User selected a node with the connection tool and drags it towards a
> > second node. In this state, there should be no clipping. To achieve
this,
> > the connection should be drawn on the standard connection layer - no
> > different compared to how this currently works in gef, and cannot be
done
> > differently since the second node is not known at this point.
> >
> > 2. After the user finished creating connection, in general case, the
> > connection will have to be clipped. The clipping is dependent upon all
of
> > the successors of the common ancestor. I think that if the connection is
> > drawn in the layer associated with the common ancestor, the correct
> clipping
> > will happen automatically. To achieve this I am proposing to create a
new
> > connection layer in the common ancestor and move the connection created
on
> > step 1 to this new connection layer.
> >
> > Is step 2 above equivalent to what you call "implementing common
> ancestor"?
> > I cannot say, since I don't understand how to do "clipping at the
> connection
>
> Take a PointList and a Rectangle. Trim the beginning and end of the
> pointlist until it lies within the rectangle, which may involve removing
> points or modifying points.
>
> > router". Please provide more details. Also, shouldn't this behaviour be
> the
> > one of the gef?
>
> Nope :-) At least half of the GEF applications do not even have nestable
> containers. They are just icons and lines.
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 26 16:13:54 GMT 2024
Powered by FUDForum. Page generated in 0.04146 seconds |
] 
Search
Help
Register
Login
Home
