[ImageJ-devel] ImageJ quits twice
Curtis Rueden
ctrueden at wisc.edu
Thu Aug 7 12:00:57 CDT 2014
Hi Dscho,
> We might need to make _all_ @EventHandler methods have some default
> non-empty key based on their class and method signature. Otherwise, it
> will only be possible to override behavior of EventHandler methods that
> take care to provide such a key.
Mark and I looked into doing this, and _almost_ pushed some changes to that
effect. However, we realized that it only makes sense to provide a key in
the case of singletons. So, for services, it makes sense, but for e.g. a
display viewer that listens for DisplayDeletedEvent, it would wreak havoc
to limit event handling to only a single instance. We considered adding
some cleverness around SingletonPlugin, or even just Service (i.e.:
generate a default key if the @EventHandler is in a class compatible with
Service), but even then, you may or may not actually want to limit the
behavior, depending on which layer of an abstract class hierarchy the event
handling method is in.
So for now, until we have a concrete use case otherwise, we are holding off
on assigning any default keys. It should be "opt in" -- i.e., a conscious
choice -- to say "limit this event handler to only _one_ instance."
-Curtis
On Thu, Aug 7, 2014 at 3:56 AM, Johannes Schindelin <schindelin at wisc.edu>
wrote:
> Hi Curtis,
>
> On Wed, 6 Aug 2014, Curtis Rueden wrote:
>
> > P.S. For the very technically inclined (*squints at Dscho*), as well as
> the
> > archives:
>
> *squints back*
>
> > We might need to make _all_ @EventHandler methods have some default
> > non-empty key based on their class and method signature. Otherwise, it
> > will only be possible to override behavior of EventHandler methods that
> > take care to provide such a key.
>
> I fully agree!
>
> Thanks for the concise and informative explanation!
> Dscho
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140807/492bdcfa/attachment.html>
More information about the ImageJ-devel
mailing list