Ticket #646 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

IJ2 App bar does not accept events

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-b1-initial
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 8 years ago by curtis

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.

comment:2 Changed 8 years ago by curtis

  • Milestone changed from biweekly-2011: Jul-18 to Jul-29 to imagej-2.0-beta1

comment:3 Changed 7 years ago by curtis

  • Status changed from new to accepted

comment:4 Changed 7 years ago 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 7 years ago by bdezonia

In 5bc3c3626c11fa96aa8e56d4a19d25bf56c8411d put in above logic for terminating a shadows demo when the app generates the ESC key event

Note: See TracTickets for help on using tickets.