Ticket #742 (closed defect: fixed)

Opened 8 years ago

Last modified 8 years ago

The App might need to do event dispatching

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-b1-initial
Component: Event Framework Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking:

Description

Before Grant's refactor of the Display hierarchy (and also Curtis' later work) there were issues where certain key and mouse events were not tracked when no image was open. There was the idea that the App might have to forward events and fill in the affected Display parameter as null. I'm not sure this is needed anymore. Soliciting comments from others.

Change History

comment:1 Changed 8 years ago by curtis

I don't think the app window needs to listen to key events. (At least, not for this purpose.)

There are two kinds of key events. The first is those that are menu shortcuts that trigger a menu item. These already work. The second is those that are passed along to the tools and associate the active display. If the main app window is in focus, pressing such keys should NOT pass on to the active display, IMO. So, I don't see why we need the app window to listen to key events at all.

The only reason I can come up with is to replicate IJ1's functionality where pressing a key without the modifier still triggers the menu item (e.g., L instead of Ctrl+L or Cmd+L). If we want to retain that behavior, we may need a similar hack like IJ1 has; haven't investigated.

comment:2 Changed 8 years ago by curtis

Another possible reason is as detailed in ticket #646: some interactive plugins such as Shadows Demo manually subscribe to key events and behavior currently differs from IJ1 in that if Esc is pressed while the main window has the focus, nothing happens.

comment:3 Changed 8 years ago by curtis

  • Status changed from new to accepted

comment:4 Changed 8 years ago by curtis

  • Status changed from accepted to closed
  • Resolution set to fixed

Fixed in 21c44aa89c7ce812c49ef41fc2c186b777e31e1d.

The app frame now publishes key events with a null display. The tool service passes such events to any active tool with its "activeInAppFrame" flag enabled (which it is not by default). Currently, the only tool that is activeInAppFrame is the AcceleratorHandler, which provides more liberal interpretation of key presses to launch commands (e.g., pressing L launches the Command Finder, like in IJ1).

Note: See TracTickets for help on using tickets.