| create different selection handles based on different requests/tools [message #248602] |
Fri, 24 April 2009 09:06  |
|
Hi all,
I've got a little problem with selection. In most editors, there is one
selection tool (or different tools but they are all creating the same
type of selection). In my case, I want to use different selection
tools. For example one tool for only moving, and other one for only
resizing. Or a tool for something completely different.
In order to add my own tool, I have implemented the following classes:
1. MySelectionEditPolicyProvider: installs MySelectionHandlesPolicy on
parent edit parts (GMF style for injecting policies)
2. MySelectionHandlesPolicy: installs MySelectionEditPolicy at all
children of its host edit part
3. MySelectionEditPolicy: create handles and feedback figures for my
special selection operation,
i.e. instances of MySelectionFeedbackFigure
4. MySelectionHandle: creates handle figure and MySelectionTracker.
5. MySelectionFeedbackFigure: the dropformation feedback figure
6. MySelectionTool: Initially creates a MySelectionTracker.
7. MySelectionTracker: Creates a MySelectionRequest.
8. MySelectionRequest: Used in .. policy to create a MySelectionCommand.
OK, so far so good, my selection stuff is working. The problem is: It
is also activated on "normal" selection. The problem is as follows:
The "normal" SelectionTool handles the mouseDown event. That is it
calls a SelectEditPartTracker to perform the selection. This one causes
the viewer to add the edit part (under the mouse cursor) to be added to
the selection (managed by the SelectionManager). This is all ok,
MySelectionTool is doing the very same thing as I want to reuse the
whole selection management infrastructure. Now the edit part is
selected (AbstractEditPart.setSelected(int)).
The problem now is as follows:
Instead of using a policy to create the selection handles via the chain
of responsibility, the edit part fires an event. Since my
MySelectionEditPolicy is working just like the original
SelectionEditPolicy, is has registered itself as a listener (otherwise
my new selection wouldn't work neither). Instead of beeing called vie
the chain of responsibility with an appropriate Request, the policy is
called via the listener interface (setSelectedState(int)), which leads
to the creation of MySelectionHandles. Later on, the "policy-API" is
used to process the request, but the wrong selection handles have been
created. I certainly could change my policy to behave differently, but
in this case the "original, normal" selection policy would create all
the handles.
Summary: The creation of the handles is triggered not via the edit
parts policy list (the chain of responsibilty) but via the listener
mechanism. This way, no information is available what type of handles
should be created, since the creating instance (in this case the
policies) has no information about the request.
IMHO this is a design flaw (the handles are created by a policy, but
the policy isn't called via the policy pattern), but maybe I have
overseen something. So, my final question is:
Is it possible to create different selection handles based on different
requests/tools?
Cheers
Jens
|
|
|
|
|
| Re: create different selection handles based on different requests/tools [message #248947 is a reply to message #248917] |
Wed, 13 May 2009 09:06  |
|
Gerrit,
On 2009-05-12 22:10:38 +0200, g99k@hotmail.com (Gerrit ) said:
> I solved the problem by making the handles save their state and adjust
> their shape and behavior accordingly. The Tool communicates the desired
> state to the EditPolicy, which then updates all handles. A little
> cumbersome, but it works.
Thank you! Your solution is nice if you have handles, and I will surely
have a look at it. In my case, I want to create different handles in
the first place. Meanwhile I solved the problem in a similar fashion as
your approach: The EditPolicy queries the currently active tool and
then decides what to do. E.g.
in MyEditPolicy (extending ResizableEditPolicy):
----------8X----------8X----------8X----------
private boolean isMyTool() {
Tool tool = getHost().getViewer().getEditDomain().getActiveTool();
return (tool instanceof MyTool);
}
@Override
protected List createSelectionHandles() {
if (isMyTool()) {
return createMySelectionHandles();
} else {
// return standard selection handles:
return super.createSelectionHandles();
}
}
----------8X----------8X----------8X----------
The basic pattern is to provide one EditPolicy, which can handle all
kind of selection-alike requests. This EditPolicy then decides what to
do based on the currently active tool. My first idea (which didn't
worked) was to provide one EditPolicy per selection-alike request --
but that doesn't work. The disadvantage of the current solution is
that, especially when using GMF, it is impossible to add new
selection-alike tools/requests to an editor w/o further investigaion,
since one EditPolicy is required to handle it all. In other words it is
impossible to simply add a new selection-alike tool and a new
EditPolicy.
Cheers
Jens
|
|
|
Powered by
FUDForum. Page generated in 3.66872 seconds
] 
Search
Help
Register
Login
Home
