Thread: RE: [Java-gnome-hackers] Handling Events in java-gnome
Brought to you by:
afcowie
From: Jeffrey M. <Jeffrey.Morgan@BristolWest.com> - 2002-08-13 12:30:06
|
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 > |
From: Philip A. C. <pc...@td...> - 2002-08-13 13:27:52
|
On Tue, 2002-08-13 at 07:29, Jeffrey Morgan wrote: > Sorry for taking so long replying to the list. I had a=20 > family emergency Friday night that has occupied all of=20 > my time until now. I think using a container of=20 > WeakReferences is a good idea.=20 I hope everything is OK now. Thanks for your vote of confidence on using WeakReferences. > 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. I agree. As you say, we could probably lump a lot of similar events into a single method for the listener interface. With this many events, it's probably not a good idea to create a parent event and subclass it for each individual type. We could probably get away with a type property in the event and an enumeration of what those types can be.=20 The downside is that the event model would get very "chatty" as the listener will be called many different times for many different events types when it only wants a particular type. May I suggest that each event have a type field whos value is a long.=20 The enumeration would be bitflags. When the listener registers, it indicates which specific event types it wants to listen to in the form of a long value. That way the notifier will only call the event for listeners which request it. Thanks, > To server as an example of this I hope to complete gtk.Widget > today. >=20 > -Jeff --=20 Philip A. Chapman |