Home » Eclipse Projects » GEF » Viewer finds EditParts?
| Viewer finds EditParts? [message #97956] |
Wed, 08 October 2003 16:25  |
Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
Why does it seem that the viewer is responsible for finding the EditParts
(hit testing) as opposed to the EditParts themselves. Seems like each
edit part should receive the hit point, and ask its children if it hits
them or not. Thus giving the edit part an opportunity to not reveal its
children if it should so desire.
Plus even worse is the viewer finding the topmost figure. that brakes
the notion of containment.
to me if feels like I have a set of editparts that have relationships to
each other, then the viewer comes along and pokes its finger of selection
right through the whole architecture and grabs at the figure.
In my opinion, figures should not be selection targets, but only edit
parts.
currently grouping is a simple form of containment. each component
unfortunately is still exposed to selection.
I am trying to create a groupEdit part. Looks like for this to work I am
going to have to go outside of the architecture. I am going to create a
GroupEditPart, but it will not use 'add' to add children, but a new
GroupAdd feature that will refuse to expose these children (but still
involves them in the drawing process). Maybe I need a groupable interface
that adds a few methods like that. also so that one can tell its a
grouped EditPart, but its class really gives that away.
*Hopefully the viewer is only able to detect or select figures that the
RootEditPart has a path too.*
So far I have decided that my GroupPartsRequest will be its own request
and not a superset of ORPHAN and ADD. So anyparts wanting to deal
specially upon ORPHAN or ADD will have to know a similar thing will happen
during GROUP and respond appropriately.
I hope I am on the right track. Anyone done this before? Care to offer
guidance?
CL
|
|
|
| Re: Viewer finds EditParts? [message #97986 is a reply to message #97956] |
Wed, 08 October 2003 20:27  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
All you need is a groupfigure which has a boolean switch. When true,
findFigureAt(...) will never return the children contained inside the group,
and therefore the editparts corresponding to those figures will never be
hit.
class GroupFigure extends Figure {
....
public boolean findFigureAt(int x, int y, TreeSearch s) {
IFigure f = super.findFigureAt(x, y, s);
if (!isGroupingEnabled() && f != null)
return this;
return f;
}
}
There are lots of other ways to do this too.
"CL [dnoyeB] Gilbert" <ThisisFake@Fakeness.xyz> wrote in message
news:pan.2003.10.08.20.25.52.763371@Fakeness.xyz...
> Why does it seem that the viewer is responsible for finding the EditParts
> (hit testing) as opposed to the EditParts themselves. Seems like each
> edit part should receive the hit point, and ask its children if it hits
> them or not. Thus giving the edit part an opportunity to not reveal its
> children if it should so desire.
>
> Plus even worse is the viewer finding the topmost figure. that brakes
> the notion of containment.
> to me if feels like I have a set of editparts that have relationships to
> each other, then the viewer comes along and pokes its finger of selection
> right through the whole architecture and grabs at the figure.
>
> In my opinion, figures should not be selection targets, but only edit
> parts.
>
> currently grouping is a simple form of containment. each component
> unfortunately is still exposed to selection.
>
> I am trying to create a groupEdit part. Looks like for this to work I am
> going to have to go outside of the architecture. I am going to create a
> GroupEditPart, but it will not use 'add' to add children, but a new
> GroupAdd feature that will refuse to expose these children (but still
> involves them in the drawing process). Maybe I need a groupable interface
> that adds a few methods like that. also so that one can tell its a
> grouped EditPart, but its class really gives that away.
>
> *Hopefully the viewer is only able to detect or select figures that the
> RootEditPart has a path too.*
>
>
> So far I have decided that my GroupPartsRequest will be its own request
> and not a superset of ORPHAN and ADD. So anyparts wanting to deal
> specially upon ORPHAN or ADD will have to know a similar thing will happen
> during GROUP and respond appropriately.
>
>
>
> I hope I am on the right track. Anyone done this before? Care to offer
> guidance?
>
>
>
> CL
|
|
|
| Re: Viewer finds EditParts? [message #98029 is a reply to message #97986] |
Wed, 08 October 2003 22:21 |
| Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
On Wed, 08 Oct 2003 20:27:32 -0400, Randy Hudson wrote:
> All you need is a groupfigure which has a boolean switch. When true,
> findFigureAt(...) will never return the children contained inside the
> group, and therefore the editparts corresponding to those figures will
> never be hit.
>
> class GroupFigure extends Figure {
>
> ...
>
> public boolean findFigureAt(int x, int y, TreeSearch s) {
> IFigure f = super.findFigureAt(x, y, s); if (!isGroupingEnabled() &&
> f != null)
> return this;
> return f;
> }
> }
>
> }
> There are lots of other ways to do this too.
>
>
Unfortunately it would appear that anything short of the Model is subject
to be discarded and recreated.. If I put something in the figure, it may
not last long enough. Even the EditPart can be recreated. The editpart
even has a functioning isSelectable() method on it. Problem here is the
command does not create the editpart, the factory does. command only
creates the model and inserts them into the parent. Then lets the
'parent' model inform all listeners to update. A side effect of which is
to instantiate an appropriate EditPart for said model. Which in turn
makes the appropriate figure.
Thus, its got to be on the Model.
I would rather have a isInGroup() method in addition to isSelectable()
though. This way its more obvious what is happening.
Perhaps if I have my topmost model have a method, isGrouped(), then each
model can let its editPart know wether or not its selectable.
I'm going to try this and how it looks.
CL
|
|
|
| Re: Viewer finds EditParts? [message #98087 is a reply to message #98029] |
Thu, 09 October 2003 10:16 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"CL [dnoyeB] Gilbert" <ThisisFake@Fakeness.xyz> wrote in message
news:pan.2003.10.09.02.21.23.665839@Fakeness.xyz...
> On Wed, 08 Oct 2003 20:27:32 -0400, Randy Hudson wrote:
>
> > All you need is a groupfigure which has a boolean switch. When true,
> > findFigureAt(...) will never return the children contained inside the
> > group, and therefore the editparts corresponding to those figures will
> > never be hit.
> >
> > class GroupFigure extends Figure {
> >
> > ...
> >
> > public boolean findFigureAt(int x, int y, TreeSearch s) {
> > IFigure f = super.findFigureAt(x, y, s); if (!isGroupingEnabled() &&
> > f != null)
> > return this;
> > return f;
> > }
> > }
> >
> > }
> > There are lots of other ways to do this too.
> >
> >
> Unfortunately it would appear that anything short of the Model is subject
> to be discarded and recreated.. If I put something in the figure, it may
Yes, I'm quite familiar with this process. Obviously the figure is
reflecting an attribute somewhere in your model. I was just illustrating
one way of disabling targeting.
> Perhaps if I have my topmost model have a method, isGrouped(), then each
> model can let its editPart know wether or not its selectable.
Sure, or instead of polluting the interface, create a utility class which
walks up the parent chain looking for instances of the group container.
|
|
|
| Re: Viewer finds EditParts? [message #98133 is a reply to message #98087] |
Thu, 09 October 2003 13:56 |
| Eclipse User |
|
|
|
Originally posted by: ThisisFake.Fakeness.xyz
It worked out well. I had to bang my head for a while though as I keep
forgeting I can't experiment with sizes on figures because they are almost
immediately overwritten with the size from the model(which was 0,0).
>> Perhaps if I have my topmost model have a method, isGrouped(), then
>> each model can let its editPart know wether or not its selectable.
>
> Sure, or instead of polluting the interface, create a utility class
> which walks up the parent chain looking for instances of the group
> container.
I have my topmost model returning grouped status. It does not need to be
on the top but only on models that intend to be groupable. Anyway, what
do you mean by polluting the interface and using a utility class? I don't
understand the method you are describing here.
Thanks again for the help. I am going to do undo/redo of my grouping
next, should be very simple. Then add an Ungroup command. Then I will
have experimented enough to probably start my real application hopefully.
CL
|
|
|
Goto Forum:
Current Time: Fri May 09 19:04:51 EDT 2025
Powered by FUDForum. Page generated in 0.03786 seconds |
Home