[ImageJ-devel] EventBus issues.
Lee Kamentsky
leek at broadinstitute.org
Thu Jun 30 13:29:04 CDT 2011
Thanks, hope this all helps to get it right.
On 6/30/2011 2:27 PM, Curtis Rueden wrote:
> Hi Grant et. al,
>
> Grant and I discussed this further, and we agree that it is much
> preferred to avoid depending on or altering the order events are
> delivered to subscribers. It should always be possible to create
> additional event types to discriminate more finely, as Lee describes.
>
> So Grant, I propose that we remove the PriorityEventSubscriber stuff
> we added the other day, to avoid complexifying the events package.
> What do you think?
>
> -Curtis
>
> On Thu, Jun 23, 2011 at 12:38 PM, Lee Kamentsky
> <leek at broadinstitute.org <mailto:leek at broadinstitute.org>> wrote:
>
> IMHO - if you depend on order for events, there's a good chance
> you're not doing something right. If you depend on order, I'm
> guessing that a direct function call is the appropriate solution
> or that you are not properly modeling what is really happening.
>
> I'm guessing that this has to do with the overlay manager - that
> you've received an overlay created/deleted event and you don't
> know whether it's in the overlay manager or not. There are two
> different events here:
> * an overlay object was created or deleted
> * the overlay manager added or removed an overlay
> so, the code that is experiencing difficulty should respond to the
> appropriate event. If you have a user interface that shows the
> overlays in the manager, it's the second event that you want. If I
> guessed wrong, perhaps it follows the same pattern?
>
> --Lee
>
>
> On 6/23/2011 12:58 PM, Grant B. Harris wrote:
>
> Ooops... My bad. I thought we were using 1.2... We are
> already using 1.4. But we need to change Events framework.
> I'll take a stab at it today.
> -- Grant
>
> On 6/23/2011 12:55 PM, Grant B. Harris wrote:
>
> I think EventBus can serve us well, but I have run into a
> serious issue that demands that we move from EventBus
> version 1.2 to 1.4.
>
> Because "subscribers are called in the order in which they
> subscribed", we cannot use the EventBus (1.2) in ways that
> we need. If I have a class which is watching things (say
> a ROI Manager or the Window menu list of open displays)
> it's behavior depends on when it was subscribed. I've
> been working on this for a week and I have not found a way
> to manage this. Fortunately I discovered that as of
> version 1.3 there is a PrioritizedEventSubscriber
> (http://www.jarvana.com/jarvana/view/org/bushe/eventbus/1.3/eventbus-1.3-javadoc.jar!/org/bushe/swing/event/Prioritized.html
> <http://www.jarvana.com/jarvana/view/org/bushe/eventbus/1.3/eventbus-1.3-javadoc.jar%21/org/bushe/swing/event/Prioritized.html>)
> I think this is just what we need.
>
> (Using this priority mechanism may also eliminate the need
> for the ObjectsUpdatedEvent that I added last week.)
>
> EventBus version 1.4 is here:
> http://mvnrepository.com/artifact/org.bushe/eventbus/1.4
>
> We will need to change the Events framework a bit to add
> Prioritized Event Subscription, but otherwise I don't
> think it will require any refactoring except for the
> subscribers that need to set priority.
>
> -- Grant
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org <mailto:ImageJ-devel at imagejdev.org>
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org <mailto:ImageJ-devel at imagejdev.org>
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org <mailto:ImageJ-devel at imagejdev.org>
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110630/6e305e71/attachment.html>
More information about the ImageJ-devel
mailing list