[ImageJ-devel] EventBus issues.

[Curtis Rueden]

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>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<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
>>> http://imagejdev.org/mailman/**listinfo/imagej-devel<http://imagejdev.org/mailman/listinfo/imagej-devel>
>>>
>>
>> ______________________________**_________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagejdev.org
>> http://imagejdev.org/mailman/**listinfo/imagej-devel<http://imagejdev.org/mailman/listinfo/imagej-devel>
>>
>
>
> ______________________________**_________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/**listinfo/imagej-devel<http://imagejdev.org/mailman/listinfo/imagej-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110630/094924a5/attachment.html>