Skip to main content



      Home
Home » Eclipse Projects » GEF » Tool's event methods' EditPartViewer vs. viewerEntered()
Tool's event methods' EditPartViewer vs. viewerEntered() [message #164227] Mon, 17 January 2005 19:40 Go to next message
Eclipse UserFriend
I am attempting to understand the "why" behind passing the EditPartViewer to
each of the event methods on org.eclipse.gef.Tool. Specifically, when is
the EditPartViewer passed to Tool's event methods different from that viewer
passed to viewerEntered()?

At the present the only assumption that I can make is that because one can
switch tools without leaving the viewer (i.e. viewerEntered() is called only
once without viewerExited() called) it is necessary to provide context with
every event. But then that begs the question: why wasn't Tool.setViewer()
enforced on the switching of tools (e.g. before Tool.activate() is called)
so that the Tool always knows its EditPartViewer?

Thanks!

--
Rob Grzywinski
Re: Tool's event methods' EditPartViewer vs. viewerEntered() [message #164295 is a reply to message #164227] Tue, 18 January 2005 10:59 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

"Rob Grzywinski" <rgrzywinski@realityinteractive.com> wrote in message
news:cshlu0$svj$1@www.eclipse.org...
>I am attempting to understand the "why" behind passing the EditPartViewer
>to each of the event methods on org.eclipse.gef.Tool. Specifically, when
>is the EditPartViewer passed to Tool's event methods different from that
>viewer passed to viewerEntered()?

viewerEntered() is a mouse event I think. There can also be focus and
keyboard events which tools receive.

> At the present the only assumption that I can make is that because one can
> switch tools without leaving the viewer (i.e. viewerEntered() is called
> only once without viewerExited() called) it is necessary to provide
> context with

Again, keyboard and other issues.

> every event. But then that begs the question: why wasn't
> Tool.setViewer() enforced on the switching of tools (e.g. before
> Tool.activate() is called) so that the Tool always knows its
> EditPartViewer?

Which viewer would you use in application which has multiple viewers?
Re: Tool's event methods' EditPartViewer vs. viewerEntered() [message #164302 is a reply to message #164295] Tue, 18 January 2005 11:28 Go to previous messageGo to next message
Eclipse UserFriend
> Which viewer would you use in application which has multiple viewers?

The one that was set in setViewer() by, say, the EditDomain (since it knows
the current state) so that I don't have to keep a running tab on things.
This really boils down to: what were the factors that lead to the decision
of forcing the EditPartViewer maintenance down to the Tool rather than
keeping it up in the EditDomain (or one of its components such as the
dispatcher) where it is better encapsulated.



--
Rob Grzywinski
Re: Tool's event methods' EditPartViewer vs. viewerEntered() [message #164376 is a reply to message #164302] Tue, 18 January 2005 13:40 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

The API is equivalent to the following in SWT:
MouseListener#mouseDown(MouseEvent)
Except in SWT the event has the source, and in GEF the source is the second
parameter.

"Rob Grzywinski" <rgrzywinski@realityinteractive.com> wrote in message
news:csjdff$gpn$1@www.eclipse.org...
>> Which viewer would you use in application which has multiple viewers?
>
> The one that was set in setViewer() by, say, the EditDomain (since it
> knows the current state) so that I don't have to keep a running tab on
> things. This really boils down to: what were the factors that lead to the
> decision of forcing the EditPartViewer maintenance down to the Tool rather
> than keeping it up in the EditDomain (or one of its components such as the
> dispatcher) where it is better encapsulated.
>
>
>
> --
> Rob Grzywinski
>
Re: Tool's event methods' EditPartViewer vs. viewerEntered() [message #164424 is a reply to message #164376] Tue, 18 January 2005 15:12 Go to previous messageGo to next message
Eclipse UserFriend
> The API is equivalent to the following in SWT:
> MouseListener#mouseDown(MouseEvent)
> Except in SWT the event has the source, and in GEF the source is the
> second parameter.

I will assert that the motivation behind the two APIs differ (and is a great
reason why design decisions should be clearly indicated within the code --
if you don't know why something was done the way it was then it is difficut
to judge if it is suitable for another situation) and that it would be much
simpler in the Tool case to have a viewerChanged() event and remove the
"context" (source) parameter. But this is obviously my opinion.

Thanks for the background so that I can plow forward with a bit more
understanding.

--
Rob Grzywinski
Re: Tool's event methods' EditPartViewer vs. viewerEntered() [message #164621 is a reply to message #164424] Wed, 19 January 2005 11:46 Go to previous message
Eclipse UserFriend
Originally posted by: none.us.ibm.com

You would be limiting what the tool could do if it did not know the reason
that the viewer was changing or going away.

"Rob Grzywinski" <rgrzywinski@realityinteractive.com> wrote in message
news:csjqj6$l92$1@www.eclipse.org...
>> The API is equivalent to the following in SWT:
>> MouseListener#mouseDown(MouseEvent)
>> Except in SWT the event has the source, and in GEF the source is the
>> second parameter.
>
> I will assert that the motivation behind the two APIs differ (and is a
> great reason why design decisions should be clearly indicated within the
> code -- if you don't know why something was done the way it was then it
> is difficut to judge if it is suitable for another situation) and that it
> would be much simpler in the Tool case to have a viewerChanged() event and
> remove the "context" (source) parameter. But this is obviously my
> opinion.
>
> Thanks for the background so that I can plow forward with a bit more
> understanding.
>
> --
> Rob Grzywinski
>
Previous Topic:New to Undo - Redo
Next Topic:Label used as ConnectionAnchor not being painted correctly.
Goto Forum:
  


Current Time: Tue Jun 17 14:10:15 EDT 2025

Powered by FUDForum. Page generated in 0.24526 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top