NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #625 (closed defect: moved)

Opened 2011-06-20T17:20:46-05:00

Last modified 2011-11-23T15:59:00-06:00

Hotkey problems in IJ2

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej-2.5.0
Component: Plugin Framework Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking:

Description

The hotkey accelerators are not completely working. As an example take the Next Axis Position and Previous Axis Position plugins. Ideally their hotkeys would be defined as GREATER and LESS and yet since they're shifted keys IJ2 can't handle it. I can fake it via setting hotkey to shift COMMA and shift PERIOD but they display poorly in the menus. This issue also affects the zoom plugins (shift EQUALS rather than PLUS).

Change History

comment:1 Changed 2011-06-23T11:07:34-05:00 by bdezonia

This is a Java issue that is still unfixed. See  http://stackoverflow.com/questions/5870685/java-swing-key-event-base for a discussion of the issue. Their workaround is the same as ours.

Wayne gets around this in IJ1 by defining ImageJ.java to be a KeyListener. It listens for the actual typing (event.getKeyChar()) of ">" and launches plugin directly. This might be his workaround to the problem. We may need to do something similar.

comment:2 Changed 2011-08-01T08:22:48-05:00 by gharris

  • Owner changed from bdezonia to gharris
  • Status changed from new to assigned
  • Milestone changed from imagej-2.0-beta2 to imagej-2.0-alpha5

comment:3 Changed 2011-08-15T09:23:31-05:00 by gharris

One approach... Add an EventSubscriber for KeyEvents and invoke the functionality there.

comment:4 Changed 2011-09-02T10:10:32-05:00 by gharris

This a now addressed with AWTKeyEventDispatcherGlobal, although there are still some focus-related issues. Specifically, the accelerator keys defined in the menus are not responsive if the focus is not on the ApplicationFrame (at least in Windows).

comment:5 Changed 2011-09-02T10:22:43-05:00 by bdezonia

On the Mac the accelerator keys are responsive whether you've selected the app bar or the image window. Testing with ">" and "<" on multidim images works correctly even when multiple images are open (moving only the sliders of the last active window).

Note this ticket has the unaddressed problem (at least on the Mac) that the accelerators for ">" and "<" show in the menus as "shift ." and "shift ,". Grant, not sure if you meant to address that part too.

comment:6 Changed 2011-11-06T22:33:56-06:00 by curtis

I believe this problem can be fixed by making the AcceleratorHandler smarter about detecting this sort of situation. If you type e.g. shift+PERIOD to get a GREATER, the event that fires has a code of PERIOD (not GREATER) with the shift modifier set. (Run the "Watch Events" plugin and give it a try.) However, the character is a '>' which means that we can potentially invoke special handling for the situation.

Once the AcceleratorHandler is smart enough to realize that shift+PERIOD should fire a command with an accelerator of GREATER on U.S. keyboards (based on analysis of the character), it won't matter that the Swing menu infrastructure ignores the key event—the AcceleratorHandler will fire the command anyway.

However, to make this work, we may need to provide a way to inquire what the given KeyCode is for a char, and vice versa.

Further investigation needed.

comment:7 Changed 2011-11-23T15:30:19-06:00 by curtis

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

(In [4482]) Change displayed shortcuts for axis pos plugins

Closes #625. It does not fully solve the issue of modifiers affecting a
key code (they still don't), nor does it make AcceleratorHandler smarter
in general, but in the case of the axis position plugins displaying <
and > accelerators in the menu, those keys *do* work now because
the AxisPositionHandler picks them up.

comment:8 Changed 2011-11-23T15:53:06-06:00 by curtis

(In [4493]) Add always-active ZoomHandler to handle +/- keys

This is instead of letting the ZoomIn and ZoomOut accelerators function,
since ZoomIn was mapped to ctrl/meta + equals, which was kind of hacky.
See #625 for details.

comment:9 Changed 2011-11-23T15:58:15-06:00 by curtis

  • Status changed from closed to reopened
  • Resolution fixed deleted

On second thought, I am reopening this ticket but pushing it to a later milestone, now that we have resolved the problem for the axis position and zoom plugin cases. It would still be good to implement a more general solution that is smart about mapping modified keys to their respective key codes.

comment:10 Changed 2011-11-23T15:59:00-06:00 by curtis

  • Milestone changed from imagej-2.0-beta1 to imagej-2.5

comment:11 Changed 2012-01-26T12:44:47-06:00 by curtis

  • Owner changed from gharris to curtis

comment:10 Changed 2014-05-01T07:00:36-05:00 by curtis

  • Status changed from reopened to closed
  • Resolution set to moved