RE: [Java-gnome-hackers] Handling Events in java-gnome

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

Sorry for taking so long replying to the list.  I had a 
family emergency Friday night that has occupied all of 
my time until now.  I think using a container of 
WeakReferences is a good idea. 

I think we should try to model our events after the standard
java event model.  We need to be careful with the events
we expose.  For example, for GtkWidget there are over 50
signals/events.  This could easily create a very complex
implementation.  My suggestion is to only expose the events
that a user of the bindings might be interested in.  Also,
if there are related events combine the notification into
a single method passing an indicator to identify which event
has occurred.

To server as an example of this I hope to complete gtk.Widget
today.

-Jeff

> Shesh,  All that typing, and I didn't attach the file....
> 
> I haven't compiled or run this code.  I hacked it from another project
> I'm working on where I use weak references for listeners.  I 
> just wanted
> to give you something to look at.
> 
> On Fri, 2002-08-09 at 13:49, Philip A. Chapman wrote:
> > Everyone,
> > 
> > As we are working on the new API for java-gnome, we should 
> think about
> > how events will be treated.  Should we use the 
> event/listener model used
> > by swing and so familiar to most Java developers?  The 
> obvious reason to
> > use it is simply because it is so familiar to Java developers.  The
> > down-side is that (a) it can be slow if you have a lot of 
> listeners or a
> > lot of different levels though which events must pass and 
> (b) developers
> > do not always unregister listeners when its usefullness has expired;
> > causing memory leaks.
> > 
> > The problem with memory leaks can be solved for the most 
> part using weak
> > references.  I'm attaching an example from one of my other 
> projects. 
> > Because this example runs in a thread and WeakHashMap is not
> > syncronized, garbage collected listeners' WeakReferences are not
> > removed.  This is not a perfect example.  I'm trading a small memory
> > leak for a potential larger one.  There are other methods.  We could
> > wrap the WeakHashMap and make is serializable.  We could use also do
> > some things with the ReferenceQueue as well.
> > 
> > Anyway, just a few thoughts.  A good reference is 
> > 
> > http://www.javaworld.com/javatips/jw-javatip79_p.html
> > 
> > 
> > Thanks,
> > -- 
> > Philip A. Chapman
> -- 
> Philip A. Chapman
>