Ticket #742 (closed defect: fixed)
Opened 2011-09-06T12:16:53-05:00
Last modified 2011-11-06T22:19:34-06:00
The App might need to do event dispatching
| Reported by: | bdezonia | Owned by: | curtis |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| 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 2011-09-06T12:28:32-05:00 by curtis
comment:2 Changed 2011-10-19T13:58:51-05:00 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:4 Changed 2011-11-06T22:19:34-06:00 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).
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.