Ticket #646 (closed defect: fixed)
Opened 2011-06-28T13:27:03-05:00
Last modified 2011-11-07T15:02:02-06:00
IJ2 App bar does not accept events
| Reported by: | bdezonia | Owned by: | curtis |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Core | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: |
Description
Not sure if this is a problem or not.
In IJ1 the app bar routed events to listeners. IJ2 does not follow this design. Rather, each display has an EventDispatcher attached to it.
This causes a (probably minor) issue in that no events are generated when you do not have an active display.
Example:
open a 2d image
select the app window
- fire the menu entry Process
- Shadows :: Shadows Demo press ESC - demo does not terminate select display window press ESC - demo terminates
Possible fixes:
- make active display always tied to some display if any are open
Do not allow app bar to take focus
- make app bar have an event displatcher attached to it so it can
forward events
- ignore this issue
Requesting feedback before doing anything on this ticket.
Change History
comment:1 Changed 2011-06-28T13:43:30-05:00 by curtis
comment:2 Changed 2011-07-27T14:46:24-05:00 by curtis
- Milestone changed from biweekly-2011: Jul-18 to Jul-29 to imagej-2.0-beta1
comment:4 Changed 2011-11-06T22:14:53-06:00 by curtis
- Status changed from accepted to closed
- Resolution set to fixed
As of 21c44aa89c7ce812c49ef41fc2c186b777e31e1d, the app frame publishes key events with a null display. Anything interested can respond to those accordingly. For example, for Shadows Demo to handle Esc from the app frame properly, it would need to do more than just check:
event.getDisplay() == currDisplay
but also check something like:
event.getDisplay() == null && imageDisplayService.getActiveImageDisplay() == currDisplay
That said, the original issue described by this ticket is resolved.
comment:5 Changed 2011-11-07T15:02:02-06:00 by bdezonia
In 5bc3c3626c11fa96aa8e56d4a19d25bf56c8411d put in above logic for terminating a shadows demo when the app generates the ESC key event
Before we go too far down this road, we should discuss some specifics of interactive plugins, and specifically plugins that listen to user input.
The design of the ImageJ2 user input events is strongly tied to displays because it was intended to interact with tools, which bind user input to actions in a display. Conversely, the IJ2 plugin design was NOT originally intended to allow interactive input. However, in the case of something like the Shadows demo that runs until the user manually terminates it, we will need to make a decision on how things should work.
Personally, I do not like that an interactive plugin must manually subscribe itself to IJ2 input events if it wants to listen to them. Perhaps there should be another, simpler mechanism for this. Keep in mind that the IJ2 plugin infrastructure is intended to be plugged into various non-ImageJ software (CellProfiler, KNIME, OMERO, Icy, etc.) and the more bells and whistles it has, the harder it is for these other programs to fully support it. We may want to create a new interface called InteractivePlugin that these interactive plugins implement, which other software can opt not to support. This interface can provide callback methods similar to the ITool interface. Perhaps InteractivePlugin and ITool can even extend the same InputListener interface? The downside is that interactive plugins must then implement ~8 callback methods even if only one of them is needed. We could get around that by having an InputAdapter abstract class similar to e.g. WindowAdapter.
In this way, the Shadows demo could avoid needing to manually subscribe to input events. However, we still need a solution to the app bar issue. It would be simple enough to add an EventDispatcher to the app bar that passes null for the display. We may want to examine other IJ1 interactive plugins before we make a final design decision about it, though.