| Multiple ConnectionLayers [message #83433] |
Wed, 11 June 2003 14:39  |
Eclipse User |
|
|
|
Originally posted by: jpl.remotejava.com
Hello,
When a node in my application becomes selected, all connections are
"highlighted" by changing their color and jumping from their default
position behind nodes to the front. The reasoning is that the user
doesn't care about most connections most of the time (so they are painted
gray and in the background), but when she makes a selection, those
connections that are important in this context should become highly
visible and easily selectable.
To implement this, I have two connection layers. I am removing/adding
the connections to the appropriate layer whenever the selection changes.
It works okay using the technique which I mentioned in the other post
today:
public class DiagramRootEditPart extends ScalableFreeformRootEditPart
{
...
protected LayeredPane createPrintableLayers()
{
FreeformLayeredPane layeredPane = new FreeformLayeredPane();
layeredPane.add(new ConnectionLayer(), CONNECTION_LAYER);
layeredPane.add(new FreeformLayer(), PRIMARY_LAYER);
layeredPane.add(new ConnectionLayer(),
HIGHLIGHTED_CONNECTION_LAYER);
return layeredPane;
}
}
However, there is a problem in the default implementation of
AbstractConnectionEditPart.deactivateFigure:
protected void deactivateFigure()
{
getLayer(CONNECTION_LAYER).remove(getFigure());
getConnectionFigure().setSourceAnchor(null);
getConnectionFigure().setTargetAnchor(null);
}
To support my two connection layers, deactivateFigure had to be overridden
to remove the connection figures from their current layer:
getFigure().getParent().remove(getFigure());
(Without it, a rather nasty runtime exception is thrown when the removal of
a figure is attempted from the wrong parent.)
I'd like to suggest to GEF developers to implement it in this manner
directly in AbstractConnectionEditPart - are there any circumstances
where it would fail? If there are none, can you think of other such
places in GEF code that would hinder multiple layers to be used?
Best regards -
Jan Ploski
|
|
|
| Re: Multiple ConnectionLayers [message #83649 is a reply to message #83433] |
Thu, 12 June 2003 15:36  |
| Eclipse User |
|
|
|
I can't think of any reason why this wouldn't work, except we should probably
check to make sure the parent isn't null before calling remove. I'll try it out
for a while and release it to the 2.2 stream if all goes well.
Eric
Jan Ploski wrote:
> Hello,
>
> When a node in my application becomes selected, all connections are
> "highlighted" by changing their color and jumping from their default
> position behind nodes to the front. The reasoning is that the user
> doesn't care about most connections most of the time (so they are painted
> gray and in the background), but when she makes a selection, those
> connections that are important in this context should become highly
> visible and easily selectable.
>
> To implement this, I have two connection layers. I am removing/adding
> the connections to the appropriate layer whenever the selection changes.
> It works okay using the technique which I mentioned in the other post
> today:
>
> public class DiagramRootEditPart extends ScalableFreeformRootEditPart
> {
> ...
>
> protected LayeredPane createPrintableLayers()
> {
> FreeformLayeredPane layeredPane = new FreeformLayeredPane();
>
> layeredPane.add(new ConnectionLayer(), CONNECTION_LAYER);
> layeredPane.add(new FreeformLayer(), PRIMARY_LAYER);
> layeredPane.add(new ConnectionLayer(),
> HIGHLIGHTED_CONNECTION_LAYER);
> return layeredPane;
> }
> }
>
> However, there is a problem in the default implementation of
> AbstractConnectionEditPart.deactivateFigure:
>
> protected void deactivateFigure()
> {
> getLayer(CONNECTION_LAYER).remove(getFigure());
> getConnectionFigure().setSourceAnchor(null);
> getConnectionFigure().setTargetAnchor(null);
> }
>
> To support my two connection layers, deactivateFigure had to be overridden
> to remove the connection figures from their current layer:
>
> getFigure().getParent().remove(getFigure());
>
> (Without it, a rather nasty runtime exception is thrown when the removal of
> a figure is attempted from the wrong parent.)
>
> I'd like to suggest to GEF developers to implement it in this manner
> directly in AbstractConnectionEditPart - are there any circumstances
> where it would fail? If there are none, can you think of other such
> places in GEF code that would hinder multiple layers to be used?
>
> Best regards -
> Jan Ploski
>
|
|
|
| Re: Multiple ConnectionLayers [message #83918 is a reply to message #83433] |
Mon, 16 June 2003 00:09 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Please open a bug to track this request. Did you override activateFigure?
What if the figure is activated for some reason while the connection is
selected (although I think that is impossible, unless you reparent both
nodes to a new container while the connection is selected).
"Jan Ploski" <jpl@remotejava.com> wrote in message
news:bc7t1c$b82$1@rogue.oti.com...
> Hello,
>
> When a node in my application becomes selected, all connections are
> "highlighted" by changing their color and jumping from their default
> position behind nodes to the front. The reasoning is that the user
> doesn't care about most connections most of the time (so they are painted
> gray and in the background), but when she makes a selection, those
> connections that are important in this context should become highly
> visible and easily selectable.
>
> To implement this, I have two connection layers. I am removing/adding
> the connections to the appropriate layer whenever the selection changes.
> It works okay using the technique which I mentioned in the other post
> today:
>
> public class DiagramRootEditPart extends ScalableFreeformRootEditPart
> {
> ...
>
> protected LayeredPane createPrintableLayers()
> {
> FreeformLayeredPane layeredPane = new FreeformLayeredPane();
>
> layeredPane.add(new ConnectionLayer(), CONNECTION_LAYER);
> layeredPane.add(new FreeformLayer(), PRIMARY_LAYER);
> layeredPane.add(new ConnectionLayer(),
> HIGHLIGHTED_CONNECTION_LAYER);
> return layeredPane;
> }
> }
>
> However, there is a problem in the default implementation of
> AbstractConnectionEditPart.deactivateFigure:
>
> protected void deactivateFigure()
> {
> getLayer(CONNECTION_LAYER).remove(getFigure());
> getConnectionFigure().setSourceAnchor(null);
> getConnectionFigure().setTargetAnchor(null);
> }
>
> To support my two connection layers, deactivateFigure had to be overridden
> to remove the connection figures from their current layer:
>
> getFigure().getParent().remove(getFigure());
>
> (Without it, a rather nasty runtime exception is thrown when the removal
of
> a figure is attempted from the wrong parent.)
>
> I'd like to suggest to GEF developers to implement it in this manner
> directly in AbstractConnectionEditPart - are there any circumstances
> where it would fail? If there are none, can you think of other such
> places in GEF code that would hinder multiple layers to be used?
>
> Best regards -
> Jan Ploski
>
|
|
|
Powered by
FUDForum. Page generated in 0.47144 seconds
Home