Home » Eclipse Projects » GEF » Layout of children & Selection
| Layout of children & Selection [message #101664] |
Thu, 23 October 2003 07:44  |
Eclipse User |
|
|
|
I have a GEF application which consists of nested figures (with the top
figure being a node - that is - it can be moved and resized). Each of the
figures are positioned relative to their parents, but otherwise their
layout is in no way dependent on the layout of the parents.
I have two questions relating to this:
1) As I have mentioned, the top level figure can be moved and resized. In
order to do this I have added the policy of type "EditPolicy.LAYOUT_ROLE"
to the parent of the editPart that generates the top level figure (the
policy is a subclass of XYLayoutEditPolicy). When I initially did this I
was getting a null pointer error on "XYLayoutEditPolicy.getConstraintFor".
Reading Randy's response to an earlier post, and looking at the Logic
example, indicated that I wasn't setting the layout constraint for the
editPart's children. I managed to get this working by overriding the
"getCurrentConstraintFor(GraphicalEditPart child)" method. However,
because the parent should in no way influence the laying out of the
children, I have written this method return an arbitry Rectangle. This
works, but my question is: am I missing something by doing this?
2) If the diagram consists of only nodes (without child figures) then I
can select it and move it and resize it (as expected from the EditPolicy).
However when it contains sub-figures I cannot (presumably the child node
is consuming the event). The intention is that when any subfigure is
selected, this leads to the selection of the node at the top of the figure
hierarchy. How do I go about implementing this?
Many thanks.
James
|
|
| |
| Re: Layout of children & Selection [message #101698 is a reply to message #101692] |
Thu, 23 October 2003 09:53  |
| Eclipse User |
|
|
|
CL [dnoyeB] Gilbert wrote:
> On Thu, 23 Oct 2003 11:44:10 +0000, James Willans wrote:
> > I have a GEF application which consists of nested figures (with the top
> > figure being a node - that is - it can be moved and resized). Each of the
> > figures are positioned relative to their parents, but otherwise their
> > layout is in no way dependent on the layout of the parents.
> >
> I don't quite follow. The child figures are inside the parent figures?
> And what do you mean by layout? are they just "grouped" with the parent?
> Hard to understand the positional and containment relationship between the
two.
> CL
Imagine my parent figure is a box with the dimensions 10,10,100,100
(x,y,width,height), a child figure might be another box with 50,50,75,75.
In terms of the positioning the child figure's 50,50 is relative to the
parents 10,10 (so absolutely 60,60). In terms of layout, the child
wouldn't be completely displayed on screen (it is clipped by the parent).
It would be necessary to enlarged the parent to display all of the child
This type of containership is a very common scenario (although I have
perhaps not explained it awfully well). For example the logic diagram has
sub-circuits, a state in a state machine diagram may have a sub diagram.
Does that add any clarity, or muddy the waters even more?
|
|
|
| Re: Layout of children & Selection [message #101735 is a reply to message #101664] |
Thu, 23 October 2003 10:38 |
| Eclipse User |
|
|
|
Originally posted by: jpl.remotejava.com
James Willans wrote:
> I have a GEF application which consists of nested figures
The statement "application consists of figures" mixes terms on different
levels of abstraction. But ok, let's just assume your application
*displays* figures, and furthermore those figures may contain other
ones (nesting).
> (with the top figure being a node - that is - it can be moved and
> resized).
The "top figure" is for me the one that holds the diagram as a whole.
Again, an unfortunate formulation, but I suppose that you really meant
that your diagram, at the highest level, contains node figures.
But you use singular. A single node figure in a diagram seems pretty
weird.
> Each of the figures are positioned relative to their parents,
> but otherwise their layout is in no way dependent on the layout
> of the parents.
Based on your clarification, I take it that you have nodes that might
contain subnodes within their bounds, and each of the parent nodes
maintains the (x,y) position of each contained subnode.
> I have two questions relating to this:
>
> 1) As I have mentioned, the top level figure can be moved and resized. In
> order to do this I have added the policy of type "EditPolicy.LAYOUT_ROLE"
> to the parent of the editPart that generates the top level figure (the
> policy is a subclass of XYLayoutEditPolicy).
I call that one the "diagram editpart". So your diagram editpart is
supposed to maintain absolute coordinates of your topmost nodes, right?
> When I initially did this I was getting a null pointer error on
> "XYLayoutEditPolicy.getConstraintFor". Reading Randy's response to an
> earlier post, and looking at the Logic example, indicated that I wasn't
> setting the layout constraint for the editPart's children.
The layout manager must know where to place the child figures.
For that, it relies on a constraint associated with each figure.
The XYLayoutEditPolicy assumes that XYLayout is used as manager
in the host figure, and therefore it expects a Rectangle as
a constraint.
> I managed to get this working by overriding the
> "getCurrentConstraintFor(GraphicalEditPart child)" method. However,
> because the parent should in no way influence the laying out of the
> children, I have written this method return an arbitry Rectangle.
This makes little sense. For the topmost nodes, you should use
a constraint reflecting their position in the diagram, not just an
"arbitrary" one.
> This works, but my question is: am I missing something by doing this?
I cannot imagine how it can "work" - if the layout constraints
associated with topmost nodes in your XYLayout are all wrong, then
repositioning the topmost nodes should not be possible.
> 2) If the diagram consists of only nodes (without child figures)
Ahh... here you seem to reveal that you indeed have more than one of
your "top figure" thingies.
> then I can select it and move it and resize it (as expected from the EditPolicy).
> However when it contains sub-figures I cannot (presumably the child node
> is consuming the event). The intention is that when any subfigure is
> selected, this leads to the selection of the node at the top of the figure
> hierarchy. How do I go about implementing this?
My first guess would be to make all but the topmost node figures
non-opaque, so that containsPoint(x, y) returns false for them.
But this might have negative side-effects in other contexts.
A more concrete description of your application might provoke further
answers ;) GEF is abstract out of necessity, but I suppose you could
communicate your problem better with some examples.
-JPL
|
|
|
| Re: Layout of children & Selection [message #101759 is a reply to message #101698] |
Thu, 23 October 2003 11:13 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
So, are you saying you just want to guarantee that a container node is large
enough to display all of its children? So you want to avoid clipping?
"James Willans" <jwillans@cs.york.ac.uk> wrote in message
news:bn8mg5$e3t$1@eclipse.org...
> CL [dnoyeB] Gilbert wrote:
>
> > On Thu, 23 Oct 2003 11:44:10 +0000, James Willans wrote:
>
> > > I have a GEF application which consists of nested figures (with the
top
> > > figure being a node - that is - it can be moved and resized). Each of
the
> > > figures are positioned relative to their parents, but otherwise their
> > > layout is in no way dependent on the layout of the parents.
> > >
>
> > I don't quite follow. The child figures are inside the parent figures?
> > And what do you mean by layout? are they just "grouped" with the parent?
> > Hard to understand the positional and containment relationship between
the
> two.
>
> > CL
>
> Imagine my parent figure is a box with the dimensions 10,10,100,100
> (x,y,width,height), a child figure might be another box with 50,50,75,75.
> In terms of the positioning the child figure's 50,50 is relative to the
> parents 10,10 (so absolutely 60,60). In terms of layout, the child
> wouldn't be completely displayed on screen (it is clipped by the parent).
> It would be necessary to enlarged the parent to display all of the child
>
> This type of containership is a very common scenario (although I have
> perhaps not explained it awfully well). For example the logic diagram has
> sub-circuits, a state in a state machine diagram may have a sub diagram.
>
> Does that add any clarity, or muddy the waters even more?
>
>
|
|
| |
| Re: Layout of children & Selection [message #101916 is a reply to message #101787] |
Fri, 24 October 2003 04:48 |
| Eclipse User |
|
|
|
Thanks for everyones' replies. I can see that I didn't formulate my
questions well, so I'm going to think about my first problem a bit more.
I solved the second problem by overriding "isSelectable()" to return false
in the non-selectable editParts.
James
CL [dnoyeB] Gilbert wrote:
> I think he wants the opposite. To ensure clipping. The first direction
> my project took was like that. Use a Pane figure instead of any of a
> Freeform figure for starters. The freeformers will automatically resize
> to encompass the bounds of their children.
> I have a group edit part that works as you describe. It returns a
> Panel(). That figure has a layout on it of
> Figure f = new Panel();
> f.setLayoutManager(new XYLayout());
> f.setOpaque(false);
> return f;
> Funny thing about it is that figures can be contained in the parent
> figure, but so far to the side that they are not shown. But if you draw a
> marquee box around where the figure should be, it will be selected, but
> still not shown. then you can drag it to where you can see it on top of
> its parent.
> I think that is what you are talking about.
> CL
|
|
|
Goto Forum:
Current Time: Mon Jul 14 03:13:57 EDT 2025
Powered by FUDForum. Page generated in 0.08431 seconds |
Home