| why no tool change notification in EditDomain [message #87358] |
Tue, 15 July 2003 14:21  |
Eclipse User |
|
|
|
Twice in two days I've found myself wishing that EditDomain included a
nofication mechanism for tool changes.
Yesterday I was experimenting with paletteless applications. I wanted a way
for actions that set the current Tool to know when the Tool is deactivated
so that the action can update it's UI accordingly. For instance if the
action is represented in the UI by a radio button then when another tool
becomes active the radio button needs to pop up.
Today I was looking for a technique to dynamically set a tool's
unloadWhenFinished property, ie set it when the tool is activated based on a
user preference setting . I thought that I would use a
PaletteChangeListener, but when I'm notified that the palette has changed I
have to go to the EditDomain to get the instance of the tool that is active.
There are a couple of problems with this approach. Since the EditDomain is
also tracking the palette change this approach relies on the EditDomain's
listener being called first. Also this approach obviously only works when
the active tool can only be set by the GEF palette.
Both these problems could be solved if EditDomain had a tool activation
notification mechanism, ie:
public void setActiveTool(Tool tool) {
if (activeTool != null)
activeTool.deactivate();
activeTool = tool;
if (activeTool != null) {
activeTool.setEditDomain(this);
activeTool.activate();
fireToolChanged( tool ); // <== notify
ToolActivationListeners
}
}
and then define a ToolActivationListener interface that listeners will
implement.
Is there any reason NOT to have this mechanism in EditDomain? It seems like
this must have come up before, so maybe it was left out for a reason.
|
|
|
| Re: why no tool change notification in EditDomain [message #87373 is a reply to message #87358] |
Tue, 15 July 2003 14:39  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Open a bugzilla. No one has asked for this before.
"David Dean" <david.dean@chordiant.com> wrote in message
news:bf1gp2$a0r$1@eclipse.org...
> Twice in two days I've found myself wishing that EditDomain included a
> nofication mechanism for tool changes.
>
> Yesterday I was experimenting with paletteless applications. I wanted a
way
> for actions that set the current Tool to know when the Tool is deactivated
> so that the action can update it's UI accordingly. For instance if the
> action is represented in the UI by a radio button then when another tool
> becomes active the radio button needs to pop up.
>
> Today I was looking for a technique to dynamically set a tool's
> unloadWhenFinished property, ie set it when the tool is activated based on
a
> user preference setting . I thought that I would use a
> PaletteChangeListener, but when I'm notified that the palette has changed
I
> have to go to the EditDomain to get the instance of the tool that is
active.
>
> There are a couple of problems with this approach. Since the EditDomain is
> also tracking the palette change this approach relies on the EditDomain's
> listener being called first. Also this approach obviously only works when
> the active tool can only be set by the GEF palette.
>
> Both these problems could be solved if EditDomain had a tool activation
> notification mechanism, ie:
>
> public void setActiveTool(Tool tool) {
> if (activeTool != null)
> activeTool.deactivate();
> activeTool = tool;
> if (activeTool != null) {
> activeTool.setEditDomain(this);
> activeTool.activate();
> fireToolChanged( tool ); // <== notify
> ToolActivationListeners
> }
> }
>
> and then define a ToolActivationListener interface that listeners will
> implement.
>
> Is there any reason NOT to have this mechanism in EditDomain? It seems
like
> this must have come up before, so maybe it was left out for a reason.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03405 seconds
Home