selection event and listener design request

[Thierry Kormann <Th...@sophia.inria.fr>]

Hi,

I am currently redesigning the gvt and gvt/event package.
I have a simple question about SelectionEvent.

1. First, is it possible that SelectionEvent extends java.util.EventObject as
it's an event (the SelectionListener extends java.util.EventListener already).

I am asking this because I think it's important for our users that the API is
uniform (all other listener and events extends the appropriate util classes).

2. Is it possible to rename getType on SelectionEvent to getID (like AWT and
our other event classes) - for the same previous reason.

3. Could we imagine to provide one method per event type on SelectionListener. I
know there are some good or bad reasons to do this or not, but
in some cases we are using the AWT technic and sometimes not. I really would
like to improve the API at this time.

4. I have also implemented the GraphicsNode's dispatch method. Its purpose is
to dispatch an event of any type to the appropriate listener list. I am not
pretty sure but I think the ConcreteEventDispatcher could use this method
instead of dispatching to the processXXX methods by hand.

5. I have seen that a mouse event is cloned each time we fire a
GraphicsNodeMouseListener. It means that if we have 4 listeners on a node, we
are going to create 4 objects per mouse drag for example (which can be
numerous). In my understanding, an event should be immutable (no set method) so
can I remove the clone() and just pass the event as is to the listeners.

6. Can I merge EventDispatcher and ConcreteEventDispatcher considering the new
design?

Any comments?
Thierry

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis

Re: selection event and listener design request

[Christophe Jolif <cj...@ilog.fr>]

Thierry Kormann wrote:

> 6. Can I merge EventDispatcher and ConcreteEventDispatcher considering the new
> design?

Yes !!!!  This will simply all of this a lot!


-- 
Christophe

Re: selection event and listener design request

[Vincent Hardy <vh...@eng.sun.com>]

Thierry,

Thierry Kormann wrote:
> 
> Hi,
> 
> I am currently redesigning the gvt and gvt/event package.
> I have a simple question about SelectionEvent.
> 
> 1. First, is it possible that SelectionEvent extends java.util.EventObject as
> it's an event (the SelectionListener extends java.util.EventListener already).
> 
> I am asking this because I think it's important for our users that the API is
> uniform (all other listener and events extends the appropriate util classes).

Yes, I think it should. May be my memory is failing, but I think this
is an oversight, as I think it was our initial intention.

> 
> 2. Is it possible to rename getType on SelectionEvent to getID (like AWT and
> our other event classes) - for the same previous reason.

Yes, for the sake of consistency.

> 
> 3. Could we imagine to provide one method per event type on SelectionListener. I
> know there are some good or bad reasons to do this or not, but
> in some cases we are using the AWT technic and sometimes not. I really would
> like to improve the API at this time.

I would go for consistency, so I think we should have one method per
type,
even though it will make the code a little more verbose.

> 
> 4. I have also implemented the GraphicsNode's dispatch method. Its purpose is
> to dispatch an event of any type to the appropriate listener list. I am not
> pretty sure but I think the ConcreteEventDispatcher could use this method
> instead of dispatching to the processXXX methods by hand.
> 
> 5. I have seen that a mouse event is cloned each time we fire a
> GraphicsNodeMouseListener. It means that if we have 4 listeners on a node, we
> are going to create 4 objects per mouse drag for example (which can be
> numerous). In my understanding, an event should be immutable (no set method) so
> can I remove the clone() and just pass the event as is to the listeners.
> 

Is that right? I thought there were instances, for example on some 
mouse events, where the x/y attributes of the events are adjusted 
during the event propagation to always be relative to the component's 
origin (and not that of its parent component, for example)?

> 6. Can I merge EventDispatcher and ConcreteEventDispatcher considering the new
> design?

Yes, again for consistency with what we are doing in other areas.
V.