Home » Eclipse Projects » GEF » Reparenting child figures to children from contentPane
| Reparenting child figures to children from contentPane [message #130042] |
Fri, 30 April 2004 10:21  |
Eclipse User |
|
|
|
Hi all,
I have a figure of type FigureA and I want its children of type Model1
and Model2 not to be placed in its contentPane but in two other Panels
of type Panel1 or Panel2 that are children of the contentPane. I
thought I could tell the editparts of type EditPart1 (and EditPart2,
respectively) something like (in createFigure(), casts omitted)
Figure1 figure1 = new Figure1();
getParent().getFigure().getPanel1().add(figure1);
return figure1;
but GEF reparents the figure to FigureA's contentPane. So I thought I
say, in EditPart1::refreshVisuals():
getParent().getFigure().remove(getFigure());
getParent().getFigure().getPanel1().add(getFigure());
I tried it with the remove and without. For some objects it works and
displays correctly, for some it throws an exception:
java.lang.IndexOutOfBoundsException: IWAG0001E Figure.add(...) invalid
index
at org.eclipse.draw2d.Figure.add(Figure.java:101)
at org.eclipse.draw2d.Figure.add(Figure.java:148)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:182)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:183)
at
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
at
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:538)
at
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:221)
at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:196)
at
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:184)
at
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
at
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
I have skimmed some GEF methods and it seems to like to keep the indices
for models, editparts and figures identical, so at
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual there is
protected void addChildVisual(EditPart childEditPart, int index) {
IFigure child = ((GraphicalEditPart)childEditPart).getFigure();
getContentPane().add(child, index);
}
which leads to the IndexOutOfBoundsException later on in Figure.add(),
because the children are "kidnapped" and there are less than GEF supposes.
It seems to me GEF does not like it when reparenting children this way.
Is there another way to achieve it? From a user point of view I would
have thought (and actually did) that when returning a figure from
createFigure() that already has a parent, that might be respected and a
new parent only set when it is null. Thoughts?
Thanks and regards, Thomas.
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130355 is a reply to message #130042] |
Tue, 04 May 2004 03:35  |
| Eclipse User |
|
|
|
Sorry to be a pain, but nobody followed up on this. Is it impossible
to reparent figures deeper down the image hierarchy? Do figures for
*direct* model children mc_1, ..., mc_n of model m have to be *direct*
children fc_1, ..., fc_n of the corresponding figure f (for model m)?
And if so, why? Is there any workaround to get what I want? Or is
there any good reason I do not actually want that?
Regards, Thomas.
Thomas Maier wrote:
> Hi all,
>
> I have a figure of type FigureA and I want its children of type Model1
> and Model2 not to be placed in its contentPane but in two other Panels
> of type Panel1 or Panel2 that are children of the contentPane. I
> thought I could tell the editparts of type EditPart1 (and EditPart2,
> respectively) something like (in createFigure(), casts omitted)
>
> Figure1 figure1 = new Figure1();
> getParent().getFigure().getPanel1().add(figure1);
> return figure1;
>
> but GEF reparents the figure to FigureA's contentPane. So I thought I
> say, in EditPart1::refreshVisuals():
>
> getParent().getFigure().remove(getFigure());
> getParent().getFigure().getPanel1().add(getFigure());
>
> I tried it with the remove and without. For some objects it works and
> displays correctly, for some it throws an exception:
>
> [...]
>
> I have skimmed some GEF methods and it seems to like to keep the indices
> for models, editparts and figures identical, so at
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual there is
>
> protected void addChildVisual(EditPart childEditPart, int index) {
> IFigure child = ((GraphicalEditPart)childEditPart).getFigure();
> getContentPane().add(child, index);
> }
>
> which leads to the IndexOutOfBoundsException later on in Figure.add(),
> because the children are "kidnapped" and there are less than GEF supposes.
>
> It seems to me GEF does not like it when reparenting children this way.
> Is there another way to achieve it? From a user point of view I would
> have thought (and actually did) that when returning a figure from
> createFigure() that already has a parent, that might be respected and a
> new parent only set when it is null. Thoughts?
>
> Thanks and regards, Thomas.
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130367 is a reply to message #130042] |
Tue, 04 May 2004 03:51 |
| Eclipse User |
|
|
|
Thomas,
It might also be achieved by setting a SPECIAL layout
manager for FigureA. In the layout() method, dispatch
all children figures into sub panels.
Ryan
Thomas Maier wrote on 2004-4-30 22:21:
> Hi all,
>
> I have a figure of type FigureA and I want its children of
> type Model1 and Model2 not to be placed in its contentPane
> but in two other Panels
> of type Panel1 or Panel2 that are children of the
> contentPane. I thought I could tell the editparts of type
> EditPart1 (and EditPart2, respectively) something like (in
> createFigure(), casts omitted)
>
> Figure1 figure1 = new Figure1();
> getParent().getFigure().getPanel1().add(figure1);
> return figure1;
>
> but GEF reparents the figure to FigureA's contentPane. So
> I thought I say, in EditPart1::refreshVisuals():
>
> getParent().getFigure().remove(getFigure());
> getParent().getFigure().getPanel1().add(getFigure());
>
> I tried it with the remove and without. For some objects
> it works and displays correctly, for some it throws an
> exception:
>
> java.lang.IndexOutOfBoundsException: IWAG0001E
> Figure.add(...) invalid
> index
> at org.eclipse.draw2d.Figure.add(Figure.java:101)
> at org.eclipse.draw2d.Figure.add(Figure.java:148)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:182)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:183)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:538)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:221)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:196)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:184)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
>
> I have skimmed some GEF methods and it seems to like to
> keep the indices for models, editparts and figures
> identical, so at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
> there is
>
> protected void addChildVisual(EditPart childEditPart, int
> index) { IFigure child =
> ((GraphicalEditPart)childEditPart).getFigure();
> getContentPane().add(child, index); }
>
> which leads to the IndexOutOfBoundsException later on in
> Figure.add(), because the children are "kidnapped" and
> there are less than GEF supposes.
>
> It seems to me GEF does not like it when reparenting
> children this way.
> Is there another way to achieve it? From a user point of
> view I would have thought (and actually did) that when
> returning a figure from createFigure() that already has a
> parent, that might be respected and a
> new parent only set when it is null. Thoughts?
>
> Thanks and regards, Thomas.
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130380 is a reply to message #130355] |
Tue, 04 May 2004 03:54 |
| Eclipse User |
|
|
|
If you have editparts for those panels, you can also
override the getTargetEditPart(Request req) method in
editPartA, and delegate requests, i.e. REQ_CREATE_CHILDREN,
REQ_MOVE_CHILDREN to the panel editparts.
Thomas Maier wrote on 2004-5-4 15:35:
> Sorry to be a pain, but nobody followed up on this. Is it
> impossible
> to reparent figures deeper down the image hierarchy? Do
> figures for *direct* model children mc_1, ..., mc_n of
> model m have to be *direct* children fc_1, ..., fc_n of
> the corresponding figure f (for model m)?
> And if so, why? Is there any workaround to get what I
> want? Or is there any good reason I do not actually want
> that?
>
> Regards, Thomas.
>
> Thomas Maier wrote:
>> Hi all,
>>
>> I have a figure of type FigureA and I want its children
>> of type Model1 and Model2 not to be placed in its
>> contentPane but in two other Panels
>> of type Panel1 or Panel2 that are children of the
>> contentPane. I thought I could tell the editparts of
>> type EditPart1 (and EditPart2, respectively) something
>> like (in createFigure(), casts omitted)
>>
>> Figure1 figure1 = new Figure1();
>> getParent().getFigure().getPanel1().add(figure1);
>> return figure1;
>>
>> but GEF reparents the figure to FigureA's contentPane.
>> So I thought I say, in EditPart1::refreshVisuals():
>>
>> getParent().getFigure().remove(getFigure());
>> getParent().getFigure().getPanel1().add(getFigure());
>>
>> I tried it with the remove and without. For some objects
>> it works and displays correctly, for some it throws an
>> exception:
>>
> > [...]
>>
>> I have skimmed some GEF methods and it seems to like to
>> keep the indices for models, editparts and figures
>> identical, so at
>>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
>> there is
>>
>> protected void addChildVisual(EditPart childEditPart, int
>> index) {
>> IFigure child =
>> ((GraphicalEditPart)childEditPart).getFigure();
>> getContentPane().add(child, index);
>> }
>>
>> which leads to the IndexOutOfBoundsException later on in
>> Figure.add(), because the children are "kidnapped" and
>> there are less than GEF supposes.
>>
>> It seems to me GEF does not like it when reparenting
>> children this way.
>> Is there another way to achieve it? From a user point of
>> view I would have thought (and actually did) that when
>> returning a figure from createFigure() that already has a
>> parent, that might be respected and a
>> new parent only set when it is null. Thoughts?
>>
>> Thanks and regards, Thomas.
>>
>
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130393 is a reply to message #130367] |
Tue, 04 May 2004 03:58 |
| Eclipse User |
|
|
|
or override figureA's add,remove,getChildren,etc methods.
ryanp wrote on 2004-5-4 15:51:
> Thomas,
>
> It might also be achieved by setting a SPECIAL layout
> manager for FigureA. In the layout() method, dispatch
> all children figures into sub panels.
>
> Ryan
>
> Thomas Maier wrote on 2004-4-30 22:21:
>
>> Hi all,
>>
>> I have a figure of type FigureA and I want its children
>> of type Model1 and Model2 not to be placed in its
>> contentPane but in two other Panels
>> of type Panel1 or Panel2 that are children of the
>> contentPane. I thought I could tell the editparts of
>> type EditPart1 (and EditPart2, respectively) something
>> like (in createFigure(), casts omitted)
>>
>> Figure1 figure1 = new Figure1();
>> getParent().getFigure().getPanel1().add(figure1);
>> return figure1;
>>
>> but GEF reparents the figure to FigureA's contentPane.
>> So I thought I say, in EditPart1::refreshVisuals():
>>
>> getParent().getFigure().remove(getFigure());
>> getParent().getFigure().getPanel1().add(getFigure());
>>
>> I tried it with the remove and without. For some objects
>> it works and displays correctly, for some it throws an
>> exception:
>>
>> java.lang.IndexOutOfBoundsException: IWAG0001E
>> Figure.add(...) invalid
>> index
>> at org.eclipse.draw2d.Figure.add(Figure.java:101)
>> at org.eclipse.draw2d.Figure.add(Figure.java:148)
>> at
>>
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractGraphicalEditPart.java:182)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:183)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
>> at
>>
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphicalEditPart.java:538)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:221)
>> at
>>
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphicalEditPart.java:196)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:184)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.java:742)
>> at
>>
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694)
>>
>> I have skimmed some GEF methods and it seems to like to
>> keep the indices for models, editparts and figures
>> identical, so at
>>
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
>> there is
>>
>> protected void addChildVisual(EditPart childEditPart, int
>> index) { IFigure child =
>> ((GraphicalEditPart)childEditPart).getFigure();
>> getContentPane().add(child, index); }
>>
>> which leads to the IndexOutOfBoundsException later on in
>> Figure.add(), because the children are "kidnapped" and
>> there are less than GEF supposes.
>>
>> It seems to me GEF does not like it when reparenting
>> children this way.
>> Is there another way to achieve it? From a user point of
>> view I would have thought (and actually did) that when
>> returning a figure from createFigure() that already has a
>> parent, that might be respected and a
>> new parent only set when it is null. Thoughts?
>>
>> Thanks and regards, Thomas.
>>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130420 is a reply to message #130367] |
Tue, 04 May 2004 05:10 |
| Eclipse User |
|
|
|
ryanp wrote:
> Thomas,
>
> It might also be achieved by setting a SPECIAL layout
> manager for FigureA. In the layout() method, dispatch
> all children figures into sub panels.
Thanks a lot for your ideas, Ryan. However I have a feeling that
using your first one does not work because I think that is basically
the same I am doing right now: I "kidnap" some of the children and GEF
seems to be "exceptionally surprised" that the number of *direct*
children is less than it thinks:
>>I have skimmed some GEF methods and it seems to like to
>>keep the indices for models, editparts and figures
>>identical, so at
>>
>
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
>
>>there is
>>
>>protected void addChildVisual(EditPart childEditPart, int
>>index) { IFigure child =
>>((GraphicalEditPart)childEditPart).getFigure();
>>getContentPane().add(child, index); }
>>
>>which leads to the IndexOutOfBoundsException later on in
>>Figure.add(), because the children are "kidnapped" and
>>there are less than GEF supposes.
>>
>>It seems to me GEF does not like it when reparenting
>>children this way.
>>Is there another way to achieve it? From a user point of
>>view I would have thought (and actually did) that when
>>returning a figure from createFigure() that already has a
>>parent, that might be respected and a
>>new parent only set when it is null. Thoughts?
Or does it matter when I reparent the children?
Thomas
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130433 is a reply to message #130380] |
Tue, 04 May 2004 05:22 |
| Eclipse User |
|
|
|
ryanp wrote:
> If you have editparts for those panels, you can also
> override the getTargetEditPart(Request req) method in
> editPartA, and delegate requests, i.e. REQ_CREATE_CHILDREN,
> REQ_MOVE_CHILDREN to the panel editparts.
>
I guess I do not have editparts for the panels, because I do not have
objects for the panels on the model side. Having models would not be
the right thing. So I guess this one doesn't work either?
Thanks anyway, Thomas.
> Thomas Maier wrote on 2004-5-4 15:35:
>
>
>>Sorry to be a pain, but nobody followed up on this. Is it
>>impossible
>>to reparent figures deeper down the image hierarchy? Do
>>figures for *direct* model children mc_1, ..., mc_n of
>>model m have to be *direct* children fc_1, ..., fc_n of
>>the corresponding figure f (for model m)?
>>And if so, why? Is there any workaround to get what I
>>want? Or is there any good reason I do not actually want
>>that?
>>
>>Regards, Thomas.
>>
>>Thomas Maier wrote:
>>
>>>Hi all,
>>>
>>>I have a figure of type FigureA and I want its children
>>>of type Model1 and Model2 not to be placed in its
>>>contentPane but in two other Panels
>>>of type Panel1 or Panel2 that are children of the
>>>contentPane. I thought I could tell the editparts of
>>>type EditPart1 (and EditPart2, respectively) something
>>>like (in createFigure(), casts omitted)
>>>
>>> Figure1 figure1 = new Figure1();
>>> getParent().getFigure().getPanel1().add(figure1);
>>> return figure1;
>>>
>>>but GEF reparents the figure to FigureA's contentPane.
>>>So I thought I say, in EditPart1::refreshVisuals():
>>>
>>> getParent().getFigure().remove(getFigure());
>>> getParent().getFigure().getPanel1().add(getFigure());
>>>
>>>I tried it with the remove and without. For some objects
>>>it works and displays correctly, for some it throws an
>>>exception:
>>>
>>
>> > [...]
>>
>>>I have skimmed some GEF methods and it seems to like to
>>>keep the indices for models, editparts and figures
>>>identical, so at
>>>
>
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
>
>>>there is
>>>
>>>protected void addChildVisual(EditPart childEditPart, int
>>>index) {
>>> IFigure child =
>>> ((GraphicalEditPart)childEditPart).getFigure();
>>> getContentPane().add(child, index);
>>>}
>>>
>>>which leads to the IndexOutOfBoundsException later on in
>>>Figure.add(), because the children are "kidnapped" and
>>>there are less than GEF supposes.
>>>
>>>It seems to me GEF does not like it when reparenting
>>>children this way.
>>>Is there another way to achieve it? From a user point of
>>>view I would have thought (and actually did) that when
>>>returning a figure from createFigure() that already has a
>>>parent, that might be respected and a
>>>new parent only set when it is null. Thoughts?
>>>
>>>Thanks and regards, Thomas.
>>>
>>
>>
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| | |
| Re: Reparenting child figures to children from contentPane [message #130670 is a reply to message #130042] |
Tue, 04 May 2004 16:18 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
There are two approaches to this problem.
1) Create several other structural features which are similar to the
children feature. You basically have to copy fields and code to make these
new features behave like children
2) Introduce grouping editparts for each panel. These editparts are
probably not selectable. You can optionally make them targetable, depending
on how you want to handle things.
Most people do 2).
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:409260F5.7070602@uni-kassel.de...
> Hi all,
>
> I have a figure of type FigureA and I want its children of type Model1
> and Model2 not to be placed in its contentPane but in two other Panels
> of type Panel1 or Panel2 that are children of the contentPane. I
> thought I could tell the editparts of type EditPart1 (and EditPart2,
> respectively) something like (in createFigure(), casts omitted)
>
> Figure1 figure1 = new Figure1();
> getParent().getFigure().getPanel1().add(figure1);
> return figure1;
>
> but GEF reparents the figure to FigureA's contentPane. So I thought I
> say, in EditPart1::refreshVisuals():
>
> getParent().getFigure().remove(getFigure());
> getParent().getFigure().getPanel1().add(getFigure());
>
> I tried it with the remove and without. For some objects it works and
> displays correctly, for some it throws an exception:
>
> java.lang.IndexOutOfBoundsException: IWAG0001E Figure.add(...) invalid
> index
> at org.eclipse.draw2d.Figure.add(Figure.java:101)
> at org.eclipse.draw2d.Figure.add(Figure.java:148)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual(AbstractG
raphicalEditPart.java:182)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:18
3)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.
java:742)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694
)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh( AbstractGraphica
lEditPart.java:538)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addNotify(Abstrac tEditPart.java:2
21)
> at
>
org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotif y(AbstractGraphi
calEditPart.java:196)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.addChild(Abstract EditPart.java:18
4)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(A bstractEditPart.
java:742)
> at
>
org.eclipse.gef.editparts.AbstractEditPart.refresh(AbstractE ditPart.java:694
)
>
> I have skimmed some GEF methods and it seems to like to keep the indices
> for models, editparts and figures identical, so at
> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual there
is
>
> protected void addChildVisual(EditPart childEditPart, int index) {
> IFigure child = ((GraphicalEditPart)childEditPart).getFigure();
> getContentPane().add(child, index);
> }
>
> which leads to the IndexOutOfBoundsException later on in Figure.add(),
> because the children are "kidnapped" and there are less than GEF supposes.
>
> It seems to me GEF does not like it when reparenting children this way.
> Is there another way to achieve it? From a user point of view I would
> have thought (and actually did) that when returning a figure from
> createFigure() that already has a parent, that might be respected and a
> new parent only set when it is null. Thoughts?
>
> Thanks and regards, Thomas.
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130683 is a reply to message #130433] |
Tue, 04 May 2004 16:40 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Editparts do not have to have *real* corresponding model objects. You can
give them null or bogus objects such as a pair of objects representing the
original object and some key indicating the associated feature.
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:409760E5.7050809@uni-kassel.de...
> ryanp wrote:
> > If you have editparts for those panels, you can also
> > override the getTargetEditPart(Request req) method in
> > editPartA, and delegate requests, i.e. REQ_CREATE_CHILDREN,
> > REQ_MOVE_CHILDREN to the panel editparts.
> >
>
> I guess I do not have editparts for the panels, because I do not have
> objects for the panels on the model side. Having models would not be
> the right thing. So I guess this one doesn't work either?
>
> Thanks anyway, Thomas.
>
>
> > Thomas Maier wrote on 2004-5-4 15:35:
> >
> >
> >>Sorry to be a pain, but nobody followed up on this. Is it
> >>impossible
> >>to reparent figures deeper down the image hierarchy? Do
> >>figures for *direct* model children mc_1, ..., mc_n of
> >>model m have to be *direct* children fc_1, ..., fc_n of
> >>the corresponding figure f (for model m)?
> >>And if so, why? Is there any workaround to get what I
> >>want? Or is there any good reason I do not actually want
> >>that?
> >>
> >>Regards, Thomas.
> >>
> >>Thomas Maier wrote:
> >>
> >>>Hi all,
> >>>
> >>>I have a figure of type FigureA and I want its children
> >>>of type Model1 and Model2 not to be placed in its
> >>>contentPane but in two other Panels
> >>>of type Panel1 or Panel2 that are children of the
> >>>contentPane. I thought I could tell the editparts of
> >>>type EditPart1 (and EditPart2, respectively) something
> >>>like (in createFigure(), casts omitted)
> >>>
> >>> Figure1 figure1 = new Figure1();
> >>> getParent().getFigure().getPanel1().add(figure1);
> >>> return figure1;
> >>>
> >>>but GEF reparents the figure to FigureA's contentPane.
> >>>So I thought I say, in EditPart1::refreshVisuals():
> >>>
> >>> getParent().getFigure().remove(getFigure());
> >>> getParent().getFigure().getPanel1().add(getFigure());
> >>>
> >>>I tried it with the remove and without. For some objects
> >>>it works and displays correctly, for some it throws an
> >>>exception:
> >>>
> >>
> >> > [...]
> >>
> >>>I have skimmed some GEF methods and it seems to like to
> >>>keep the indices for models, editparts and figures
> >>>identical, so at
> >>>
> >
> > org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual
> >
> >>>there is
> >>>
> >>>protected void addChildVisual(EditPart childEditPart, int
> >>>index) {
> >>> IFigure child =
> >>> ((GraphicalEditPart)childEditPart).getFigure();
> >>> getContentPane().add(child, index);
> >>>}
> >>>
> >>>which leads to the IndexOutOfBoundsException later on in
> >>>Figure.add(), because the children are "kidnapped" and
> >>>there are less than GEF supposes.
> >>>
> >>>It seems to me GEF does not like it when reparenting
> >>>children this way.
> >>>Is there another way to achieve it? From a user point of
> >>>view I would have thought (and actually did) that when
> >>>returning a figure from createFigure() that already has a
> >>>parent, that might be respected and a
> >>>new parent only set when it is null. Thoughts?
> >>>
> >>>Thanks and regards, Thomas.
> >>>
> >>
> >>
> >
>
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130696 is a reply to message #130516] |
Wed, 05 May 2004 04:52 |
| Eclipse User |
|
|
|
Gunnar Wagenknecht wrote:
> Thomas Maier wrote:
>
>
>>I have a figure of type FigureA and I want its children of type Model1
>>and Model2 not to be placed in its contentPane but in two other Panels
>>of type Panel1 or Panel2 that are children of the contentPane. I
>>thought I could tell the editparts of type EditPart1 (and EditPart2,
>>respectively) something like (in createFigure(), casts omitted)
>
>
> You should adapt your architecture. GEF assumes a strict hierarchy for
> EditPart children. There is only ONE content pane for all EditPart children.
>
> To achieve the following hierarchy:
>
> FigureA
> Panel1
> Child1
> Child2
> Panel2
> Child3
> Child4
>
> You must create the following EditPart hierarchy:
>
> EditPartA
> PanelEditPart1
> ChildEditPart1
> ChildEditPart2
> PanelEditPart2
> ChildEditPart3
> ChildEditPart4
>
> If this hierarchy doesn't reflect your model then don't worry. Create dummy
> model objects in EditPartA for every panel. Your factory will create
> PanelEditParts for these.
Hi Gunnar and Randy, thanks for your suggestions.
So I create dummy models like this:
modelA
panelDummyModel1
panelDummyModel2
I still want my children of type Model1 and Model2 to be direct
children of ModelA objects. Like that:
modelA
panelDummyModel1
panelDummyModel2
model1
model2
So I guess I would have to "guide" GEF via getModelChildren in the
edit parts to get the hierarchy I want? So I'd say in
ModelAEditPart.getModelChildren()
{
"return the two panel dummy model objects"
}
and in
PanelDummy1EditPart.getModelChildren()
{
"ModelA parentModel = getParent().getModel();"
"return the Model1-type models from parentModel"
}
and in
PanelDummy2EditPart.getModelChildren()
{
"ModelA parentModel = getParent().getModel();"
"return the Model2-type models from parentModel"
}
to trick GEF into thinking that my hierarchy is something different
than it actually is, right?
But that seems a) overly complicated and b) not like the right thing
to me. I have to admit I have not thought about it too much, but to
me the right solution seems to be able to place the figure children to
a deeper level in the hierarchy, kinda like that:
model-level-1 ----- editpart-level-1 ----- figure-level-1
| | |
| | some levels inbetween
| | |
model-level-2 ----- editpart-level-2 ----- figure-level-n
But maybe there are other problems with that approach? Or is it
simply "implemented the way it is implemented"?.
> Another solution is to provide a custom figure. This figure does not use
> real figures for the panels but simply paints the panels and it has a layout
> manager that layouts it children based on a layout contraint (which could be
> a simple constant "PANEL-xyz").
Yeah, I was thinking about custom layouts, too. But again, I thought
it was easier :).
Thanks, Thomas.
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130708 is a reply to message #130670] |
Wed, 05 May 2004 05:05 |
| Eclipse User |
|
|
|
Randy Hudson wrote:
> There are two approaches to this problem.
>
> 1) Create several other structural features which are similar to the
> children feature. You basically have to copy fields and code to make these
> new features behave like children
Randy, thanks for your follow up. But beware, I am GEF newbie. In
other words: might you please describe your first point a bit more
detailed? :)
> 2) Introduce grouping editparts for each panel. These editparts are
> probably not selectable. You can optionally make them targetable, depending
> on how you want to handle things.
Again, the newbie I am, that was a bit short for me. I guess that is
what Gunnar suggested?
Sorry and thanks, again, Thomas.
>
> Most people do 2).
>
> "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
> news:409260F5.7070602@uni-kassel.de...
>
>>Hi all,
>>
>>I have a figure of type FigureA and I want its children of type Model1
>>and Model2 not to be placed in its contentPane but in two other Panels
>>of type Panel1 or Panel2 that are children of the contentPane. I
>>thought I could tell the editparts of type EditPart1 (and EditPart2,
>>respectively) something like (in createFigure(), casts omitted)
>>
>> Figure1 figure1 = new Figure1();
>> getParent().getFigure().getPanel1().add(figure1);
>> return figure1;
>>
>>but GEF reparents the figure to FigureA's contentPane. So I thought I
>>say, in EditPart1::refreshVisuals():
>>
>> getParent().getFigure().remove(getFigure());
>> getParent().getFigure().getPanel1().add(getFigure());
>>
>>I tried it with the remove and without. For some objects it works and
>>displays correctly, for some it throws an exception:
>>
>> [exception deleted]
>>
>>I have skimmed some GEF methods and it seems to like to keep the indices
>>for models, editparts and figures identical, so at
>> org.eclipse.gef.editparts.AbstractGraphicalEditPart.addChild Visual there
>>
>> is
>>
>>protected void addChildVisual(EditPart childEditPart, int index) {
>>IFigure child = ((GraphicalEditPart)childEditPart).getFigure();
>>getContentPane().add(child, index);
>>}
>>
>>which leads to the IndexOutOfBoundsException later on in Figure.add(),
>>because the children are "kidnapped" and there are less than GEF supposes.
>>
>>It seems to me GEF does not like it when reparenting children this way.
>>Is there another way to achieve it? From a user point of view I would
>>have thought (and actually did) that when returning a figure from
>>createFigure() that already has a parent, that might be respected and a
>>new parent only set when it is null. Thoughts?
>>
>>Thanks and regards, Thomas.
>>
>>--
>>Thomas Maier <Thomas.Maier@uni-kassel.de>
>>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130733 is a reply to message #130696] |
Wed, 05 May 2004 07:04 |
| Eclipse User |
|
|
|
Thomas Maier wrote:
> Gunnar Wagenknecht wrote:
>
>> Thomas Maier wrote:
>>
>>
>>> I have a figure of type FigureA and I want its children of type Model1
>>> and Model2 not to be placed in its contentPane but in two other Panels
>>> of type Panel1 or Panel2 that are children of the contentPane. I
>>> thought I could tell the editparts of type EditPart1 (and EditPart2,
>>> respectively) something like (in createFigure(), casts omitted)
>>
>>
>>
>> You should adapt your architecture. GEF assumes a strict hierarchy for
>> EditPart children. There is only ONE content pane for all EditPart
>> children.
>>
>> To achieve the following hierarchy:
>>
>> FigureA
>> Panel1
>> Child1
>> Child2
>> Panel2
>> Child3
>> Child4
>>
>> You must create the following EditPart hierarchy:
>>
>> EditPartA
>> PanelEditPart1
>> ChildEditPart1
>> ChildEditPart2
>> PanelEditPart2
>> ChildEditPart3
>> ChildEditPart4
>>
>> If this hierarchy doesn't reflect your model then don't worry. Create
>> dummy
>> model objects in EditPartA for every panel. Your factory will create
>> PanelEditParts for these.
>
>
> Hi Gunnar and Randy, thanks for your suggestions.
>
> So I create dummy models like this:
>
> modelA
> panelDummyModel1
> panelDummyModel2
>
> I still want my children of type Model1 and Model2 to be direct children
> of ModelA objects. Like that:
>
> modelA
> panelDummyModel1
> panelDummyModel2
> model1
> model2
>
> So I guess I would have to "guide" GEF via getModelChildren in the edit
> parts to get the hierarchy I want? So I'd say in
>
> ModelAEditPart.getModelChildren()
> {
> "return the two panel dummy model objects"
> }
>
> and in
>
> PanelDummy1EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
> "return the Model1-type models from parentModel"
> }
>
> and in
>
> PanelDummy2EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
> "return the Model2-type models from parentModel"
> }
>
> to trick GEF into thinking that my hierarchy is something different than
> it actually is, right?
>
> But that seems a) overly complicated and b) not like the right thing to
> me. I have to admit I have not thought about it too much, but to me the
> right solution seems to be able to place the figure children to a deeper
> level in the hierarchy, kinda like that:
>
> model-level-1 ----- editpart-level-1 ----- figure-level-1
> | | |
> | | some levels inbetween
> | | |
> model-level-2 ----- editpart-level-2 ----- figure-level-n
>
> But maybe there are other problems with that approach? Or is it simply
> "implemented the way it is implemented"?.
>
>
>> Another solution is to provide a custom figure. This figure does not use
>> real figures for the panels but simply paints the panels and it has a
>> layout
>> manager that layouts it children based on a layout contraint (which
>> could be
>> a simple constant "PANEL-xyz").
>
>
> Yeah, I was thinking about custom layouts, too. But again, I thought it
> was easier :).
>
> Thanks, Thomas.
>
So I just implemented that trick-the-GEF thing. But unfortunately
there are more problems than I thought of. GEF insists on reordering
the editparts/figures to the indexes GEF wants them to be. This makes
it rather impossible to use standard layouts I think. I wanted to
have it like this:
FigureA should look like
+---------------------+
| some headline |
+---------------------+
| a panel containing |
| Model1 children |
+---------------------+
| a panel containing |
| Model2 children |
+---------------------+
The headline is kind of fixed and depends on on ModelA. It is
supposed to always display at the top of the figure. Unfortunately
GEF reorders its children so that when I have
modelA
panelDummyModel1
panelDummyModel2
GEF reorders the figure to
+---------------------+
| a panel containing |
| Model1 children |
+---------------------+
| a panel containing |
| Model2 children |
+---------------------+
| some baseline :( |
+---------------------+
I think it should be possible to let every figure be some kind of a
template and the editparts decide where to place the children figures
into that template. Here, ModelAEditPart would place Model1 children
into the upper panel and Model2 children into the lower panel and GEF
would not touch the figure's layout. Thoughts? GEF developers?
Regards, Thomas.
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130970 is a reply to message #130696] |
Wed, 05 May 2004 14:08 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You do not have to put the bogus model stuff in your REAL model. You just
return these things in FigureA's EditPart's getModelChildren(). Spoof them
up when you need them.
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:4098AB67.9070305@uni-kassel.de...
> Gunnar Wagenknecht wrote:
> > Thomas Maier wrote:
> >
> >
> >>I have a figure of type FigureA and I want its children of type Model1
> >>and Model2 not to be placed in its contentPane but in two other Panels
> >>of type Panel1 or Panel2 that are children of the contentPane. I
> >>thought I could tell the editparts of type EditPart1 (and EditPart2,
> >>respectively) something like (in createFigure(), casts omitted)
> >
> >
> > You should adapt your architecture. GEF assumes a strict hierarchy for
> > EditPart children. There is only ONE content pane for all EditPart
children.
> >
> > To achieve the following hierarchy:
> >
> > FigureA
> > Panel1
> > Child1
> > Child2
> > Panel2
> > Child3
> > Child4
> >
> > You must create the following EditPart hierarchy:
> >
> > EditPartA
> > PanelEditPart1
> > ChildEditPart1
> > ChildEditPart2
> > PanelEditPart2
> > ChildEditPart3
> > ChildEditPart4
> >
> > If this hierarchy doesn't reflect your model then don't worry. Create
dummy
> > model objects in EditPartA for every panel. Your factory will create
> > PanelEditParts for these.
>
> Hi Gunnar and Randy, thanks for your suggestions.
>
> So I create dummy models like this:
>
> modelA
> panelDummyModel1
> panelDummyModel2
>
> I still want my children of type Model1 and Model2 to be direct
> children of ModelA objects. Like that:
>
> modelA
> panelDummyModel1
> panelDummyModel2
> model1
> model2
>
> So I guess I would have to "guide" GEF via getModelChildren in the
> edit parts to get the hierarchy I want? So I'd say in
>
> ModelAEditPart.getModelChildren()
> {
> "return the two panel dummy model objects"
> }
>
> and in
>
> PanelDummy1EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
> "return the Model1-type models from parentModel"
> }
>
> and in
>
> PanelDummy2EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
> "return the Model2-type models from parentModel"
> }
>
> to trick GEF into thinking that my hierarchy is something different
> than it actually is, right?
>
> But that seems a) overly complicated and b) not like the right thing
> to me. I have to admit I have not thought about it too much, but to
> me the right solution seems to be able to place the figure children to
> a deeper level in the hierarchy, kinda like that:
>
> model-level-1 ----- editpart-level-1 ----- figure-level-1
> | | |
> | | some levels inbetween
> | | |
> model-level-2 ----- editpart-level-2 ----- figure-level-n
>
> But maybe there are other problems with that approach? Or is it
> simply "implemented the way it is implemented"?.
>
>
> > Another solution is to provide a custom figure. This figure does not use
> > real figures for the panels but simply paints the panels and it has a
layout
> > manager that layouts it children based on a layout contraint (which
could be
> > a simple constant "PANEL-xyz").
>
> Yeah, I was thinking about custom layouts, too. But again, I thought
> it was easier :).
>
> Thanks, Thomas.
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #130983 is a reply to message #130696] |
Wed, 05 May 2004 14:14 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> So I guess I would have to "guide" GEF via getModelChildren in the
> edit parts to get the hierarchy I want? So I'd say in
>
> ModelAEditPart.getModelChildren()
> {
> "return the two panel dummy model objects"
> }
Yes, or simply build the editparts yourself by overriding refreshChildren()
to completely bypass the call to getModelChildren();
> and in
>
> PanelDummy1EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
The model for PanelDummy1EditPart could be the same as the model of its
parent, if you want. Or it could be the "dummy" Model:
ModelA parentModel = ((ModelFeaturePair)getModel()).getBaseElement();
> "return the Model1-type models from parentModel"
> }
>
> and in
>
> PanelDummy2EditPart.getModelChildren()
> {
> "ModelA parentModel = getParent().getModel();"
> "return the Model2-type models from parentModel"
> }
>
> to trick GEF into thinking that my hierarchy is something different
> than it actually is, right?
I don't see any trickery. This is flexibility at its best. The visual
hierarchy does not have to reflect the model hierarchy. Try doing that in
EMF edit and see how far you get.
> But that seems a) overly complicated and b) not like the right thing
> to me. I have to admit I have not thought about it too much, but to
> me the right solution seems to be able to place the figure children to
> a deeper level in the hierarchy, kinda like that:
>
> model-level-1 ----- editpart-level-1 ----- figure-level-1
> | | |
> | | some levels inbetween
> | | |
> model-level-2 ----- editpart-level-2 ----- figure-level-n
>
> But maybe there are other problems with that approach? Or is it
> simply "implemented the way it is implemented"?.
>
>
> > Another solution is to provide a custom figure. This figure does not use
> > real figures for the panels but simply paints the panels and it has a
layout
> > manager that layouts it children based on a layout contraint (which
could be
> > a simple constant "PANEL-xyz").
>
> Yeah, I was thinking about custom layouts, too. But again, I thought
> it was easier :).
>
> Thanks, Thomas.
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
>
|
|
|
| Re: Reparenting child figures to children from contentPane [message #131297 is a reply to message #130983] |
Fri, 07 May 2004 09:11 |
| Eclipse User |
|
|
|
Randy Hudson wrote:
>>So I guess I would have to "guide" GEF via getModelChildren in the
>>edit parts to get the hierarchy I want? So I'd say in
>>
>>ModelAEditPart.getModelChildren()
>>{
>> "return the two panel dummy model objects"
>>}
>
>
> Yes, or simply build the editparts yourself by overriding refreshChildren()
> to completely bypass the call to getModelChildren();
So I should not take that "This method should <em>not</em> be
overridden." in the javadoc too serious? :) Seriously, will this
increase chances that my code breaks with later GEF versions?
>>and in
>>
>>PanelDummy1EditPart.getModelChildren()
>>{
>> "ModelA parentModel = getParent().getModel();"
>
>
> The model for PanelDummy1EditPart could be the same as the model of its
> parent, if you want. Or it could be the "dummy" Model:
> ModelA parentModel = ((ModelFeaturePair)getModel()).getBaseElement();
>
>
>> "return the Model1-type models from parentModel"
>>}
Ok, I guess I got it. But I still need an EditPart for each Figure,
right? I cannot create a template figure containing as much chrome as
I like and simply fill in the blanks (see below)?
>>
>>and in
>>
>>PanelDummy2EditPart.getModelChildren()
>>{
>> "ModelA parentModel = getParent().getModel();"
>> "return the Model2-type models from parentModel"
>>}
>>
>>to trick GEF into thinking that my hierarchy is something different
>>than it actually is, right?
>
>
> I don't see any trickery. This is flexibility at its best. The visual
> hierarchy does not have to reflect the model hierarchy. Try doing that in
> EMF edit and see how far you get.
No offense meant, but then "getModelChildren" is not the right name.
Because I do trick model children in here that in fact are no model
children. But slowly I begin to understand :). It is rather a
"getChildrenForWhichEditPartsWillBeCreated". While this is indeed
flexible, I still wonder what is a good solution to prevent the
"figure shuffling" caused by GEF's reordering:
I just implemented that thing (with different dummy models because I
did not get your point, but well). But unfortunately there are more
problems than I thought of. GEF insists on reordering the
editparts/figures to the indexes GEF wants them to be. This makes it
quite hard to use standard layouts I think. I want to have it like this:
FigureA should look like
+---------------------+
| some headline |
+---------------------+ a separator
| a panel containing |
| Model1 children |
+---------------------+ a separator
| a panel containing |
| Model2 children |
+---------------------+
The headline is kind of fixed and depends on ModelA. It is supposed
to always display at the top of the figure. Unfortunately GEF
reorders its children so that when I have
modelA
panelDummyModel1
panelDummyModel2
GEF reorders the figure to
+---------------------+
| a panel containing |
| Model1 children |
| a panel containing |
| Model2 children |
| some baseline :( |
+---------------------+ a separator
+---------------------+ a separator
+---------------------+
Of course I could implement a custom border and of course I could
inject a dummy model for the headline at the first position. Well,
after having read this post for the fourth time and switching back and
forth the GEF source, I think overriding getContentPane() simplifies
this case a bit more.
But actually, to have flexibility at its best (again, no offense
meant, I'd just love to see GEF be an even nicer piece of software
than it already is), I would like to simply stick existing stuff
together (standard figures, standard layouts) instead of wastefully
making up my own.
I have the idea to let every figure be some kind of a template and the
editparts decide where to place the children figures into that
template and not stuff everything into the content pane. Make the
content pane the default but respect a parent set by the edit part in
createFigure(). Here, ModelAEditPart would place Model1 children into
the upper panel and Model2 children into the lower panel and GEF would
not touch the figure's layout. Thoughts?
Sorry again for being such a pain, Thomas.
P.S.: I am going to give something back and write an introducion to
GEF using a *small* example because my students are having a hard time
understanding those things (and it seems I cannot blame them :>).
Would anybody of you GEF developers care and kind of proofread that
thing once I have something to show?
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| | |
| Re: Reparenting child figures to children from contentPane [message #131844 is a reply to message #131602] |
Tue, 11 May 2004 22:07 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
This would be possible, but I don't see how you would reconcile the indexes
easily. For example, if you had attributes and methods in two separate
compartments, how would you mainting the figure indexes? The methods would
probably be sorted alphabetically, but the figure index would not match the
model index.
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:40A080E7.80200@uni-kassel.de...
> Randy Hudson wrote:
> >>Ok, I guess I got it. But I still need an EditPart for each Figure,
> >
> >
> > No, and this is what is causing your ordering problem below. An
editpart
> > can have lots of figures, ONE of which is the contents pane for its
> > children. So what you need is:
> >
> > + The main figure
> > | - A Label figure for the heading
> > | - Another figure which serves as the contents pane
> >
> > Then, override getContentsPane() to return the appropriate figure.
>
> And that *still* does not work when I have *mutiple* blanks/places to
> be filled by subfigures. It takes *some* burden off the programmer,
> but not as much as it *could*.
>
> What about discussing my proposal about letting the EditParts decide
> where to place the subfigures? It *seems* to me that that would be
> more flexible, but maybe it is a stupid idea.
>
> --
> Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| |
| Re: Reparenting child figures to children from contentPane [message #132808 is a reply to message #131857] |
Tue, 18 May 2004 18:12 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Indexes are needed because you must position the children of each
compartment according to their rank in *that* compartment, and not their
rank in the model's list of children. There are existing layouts in draw2d
which will display list-like layouts based on figure index. It is also
possible that you could write a layout which used some index constraint and
ignored z-order (figure index).
"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
news:40A1DE74.9000208@uni-kassel.de...
> Well, unfortunately I am not familiar with GEF's implementation and
> the constraints you have. Why is that index stuff needed anyway?
> Without looking at the source my only guess is for quickly navigating
> through the figure/editpart/model graph? Does it have to be quick?
> When is it used? While handling events? What about Maps? Too
> heavy-weight?
> Btw, thanks for being responsive to this and generally for the loads
> of information I got from this thread :).
>
> Randy Hudson wrote:
> > This would be possible, but I don't see how you would reconcile the
indexes
> > easily. For example, if you had attributes and methods in two separate
> > compartments, how would you mainting the figure indexes? The methods
would
> > probably be sorted alphabetically, but the figure index would not match
the
> > model index.
> >
> > "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
> > news:40A080E7.80200@uni-kassel.de...
> >>[...]
> >>And that *still* does not work when I have *mutiple* blanks/places to
> >>be filled by subfigures. It takes *some* burden off the programmer,
> >>but not as much as it *could*.
> >>
> >>What about discussing my proposal about letting the EditParts decide
> >>where to place the subfigures? It *seems* to me that that would be
> >>more flexible, but maybe it is a stupid idea.
|
|
|
| Re: Reparenting child figures to children from contentPane [message #133392 is a reply to message #132808] |
Fri, 21 May 2004 03:08 |
| Eclipse User |
|
|
|
Ok, so this is crucial. An easy solution would of course be to not
explicitly use indexes but something like getFigureFor(Object model)
and getModelFor(Figure figure) instead of "give me the model at the
same index the figure is" and vice versa. It would better express
what you actually want, thus you would have clearer code. It would
also hide more details. You would of course still want to (and could)
have list semantics with something like getFigure(i) and getModel(j)
but could not expect anymore that i==j for a
model-figure-relationship. I still like the idea :).
Randy Hudson wrote:
> Indexes are needed because you must position the children of each
> compartment according to their rank in *that* compartment, and not their
> rank in the model's list of children. There are existing layouts in draw2d
> which will display list-like layouts based on figure index. It is also
> possible that you could write a layout which used some index constraint and
> ignored z-order (figure index).
>
> "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
> news:40A1DE74.9000208@uni-kassel.de...
>
>>Well, unfortunately I am not familiar with GEF's implementation and
>>the constraints you have. Why is that index stuff needed anyway?
>>Without looking at the source my only guess is for quickly navigating
>>through the figure/editpart/model graph? Does it have to be quick?
>> When is it used? While handling events? What about Maps? Too
>>heavy-weight?
>>Btw, thanks for being responsive to this and generally for the loads
>>of information I got from this thread :).
>>
>>Randy Hudson wrote:
>>
>>>This would be possible, but I don't see how you would reconcile the
>
> indexes
>
>>>easily. For example, if you had attributes and methods in two separate
>>>compartments, how would you mainting the figure indexes? The methods
>
> would
>
>>>probably be sorted alphabetically, but the figure index would not match
>
> the
>
>>>model index.
>>>
>>>"Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
>>>news:40A080E7.80200@uni-kassel.de...
>>>
>>>>[...]
>>>>And that *still* does not work when I have *mutiple* blanks/places to
>>>>be filled by subfigures. It takes *some* burden off the programmer,
>>>>but not as much as it *could*.
>>>>
>>>>What about discussing my proposal about letting the EditParts decide
>>>>where to place the subfigures? It *seems* to me that that would be
>>>>more flexible, but maybe it is a stupid idea.
>
>
>
--
Thomas Maier <Thomas.Maier@uni-kassel.de>
|
|
| |
| Re: Reparenting child figures to children from contentPane [message #135916 is a reply to message #135456] |
Thu, 03 June 2004 03:07 |
| Eclipse User |
|
|
|
And what exactly would be the problem here (I do not know how
FlowLayout works)? You still have list semantics for the figures.
Isn't the only different thing when you give the model index as a
layout constraint? The indexes are not consecutive any longer but
still partially ordered, so a simple sort with the right comparator
does the job doesn't it?
Randy Hudson wrote:
> I'm not sure how this ties into a draw2d layoutmanager which is order-based,
> such as FlowLayout. Layout would not know about models, so my suggestion
> was to specify the layout index as a constraint.
>
> "Thomas Maier" <Thomas.Maier@uni-kassel.de> wrote in message
> news:40ADAADC.1000604@uni-kassel.de...
>
>>Ok, so this is crucial. An easy solution would of course be to not
>>explicitly use indexes but something like getFigureFor(Object model)
>>and getModelFor(Figure figure) instead of "give me the model at the
>>same index the figure is" and vice versa. It would better express
>>what you actually want, thus you would have clearer code. It would
>>also hide more details. You would of course still want to (and could)
>>have list semantics with something like getFigure(i) and getModel(j)
>>but could not expect anymore that i==j for a
>>model-figure-relationship. I still like the idea :).
|
|
|
Goto Forum:
Current Time: Mon May 12 08:42:54 EDT 2025
Powered by FUDForum. Page generated in 0.07554 seconds |
Home