It looks like Swing actually offers support for this, e.g. JRootPane#setDefaultButton() method.
* The default button is the button which will be activated
* when a UI-defined activation event (typically the <b>Enter</b> key)
* occurs in the root pane regardless of whether or not the button
* has keyboard focus (unless there is another component within
* the root pane which consumes the activation event,
* such as a <code>JTextPane</code>).
I may get tempted to investigate or I may run into some brick wall.
I don’t know why no-one else has mentioned this before, but this has indeed always been the case with VASSAL. I only mention it now because palad0n specifically mentioned the related behavior on Windows. I don’t think I was using VASSAL yet in 2006, or if I was not long enough to criticize it. I have always just taken it as one of the annoying things of the VASSAL UI – expectations are generally lower with Java software.
That’s a response I’ve been fighting against, not the entire time I’ve been working on Vassal, nor even the entire time I’ve been writing software, but basically my entire adult life.
Assuming that the responsible people are aware of a problem is the best way to have decades pass without anyone who could fix the problem ever being aware of it.
I’m not castigating you here. This is a thing I’ve seen over and over, from no one person in particular. The only path to polished software is to be made aware of what’s not working. So please, please tell us when something is not working. I don’t want to be years down the line with V4 to have someone say “I noticed this thing was broken five years ago”.
Well, we have ‘put up with it’ for years, so unless Cattlesquat does not hit the proverbial brick wall, leave it for V4 to fix. Me, I’m hoping for the no brick wall.
Works great with a single window.
With multiple windows open, say several GPs or gamepieces, only the last object opened has the “OK” focus. Repeatably pressing enter closes and opens the last object clicked to open. All other open windows have lost “OK” focus.
Same applies for the ESC key.
The Windows/Mac “enter” behavior applies to the currently focused window – when you close e.g. a Game Piece window, focus returns to the parent window (the editor window itself) rather than e.g. one of the other misc configurer windows (e.g. other game pieces) you’ve opened.
I don’t remember if Windows/Mac offer default hotkeys to change focus within the subwindows of an app. Maybe not? Obviously you could always click in the other window and then hit Enter.
I suppose in some future version we could implement additional focus navigation keys, an/or some editor window key to “close ALL the configurer windows”. That would obviously be moving beyond the default Windows/Mac behavior but I could certainly imagine such a thing.
The only reason I mentioned that behaviour is that if I do happen to have multiple windows open in ‘windows’, some of which may be sub-windows of another window process, pressing enter will close each in turn. Assuming that my memory is correct here though.
On the subject of keys that don’t do their expected function (and ready to spin this off as a new request)…
UNDO in text editing! Meaning in the Editor and Player ( in the later, Notes window, Chat, Text Label edits)
At least on Mac, Cmd+Z does not undo whilst in a text edit … I can understand there’s no generalised undo function in the editor, but would text edit undo be a viable request ?
Obviously, on Windows, I’d be saying Ctrl+Z - does that work for Windows Vassal text editing I wonder ?
ctrl z is the default ‘undo’ with windows. Works almost anytime. Type a few words in word, ctrl z - gone. Play solitaire, ctrl z to undo last move.
I’ve just made my modules to use ctrl z as the hotkey for the undo action button. Why is that not a default?
Conversely, ctrl y, is the redo what you just undid.
I can’t personally think of any apps that actually work that way, where you can cascade-close a whole bunch of subwindows with e.g. ESC (fairly esoteric subclass of apps).
However it sounds like reasonably smart behavior for VASSAL (at least until someone finds something horribly wrong with the idea) – so I have created a new version that attempts to give focus to another properties configurer window (e.g. game pieces, GPs whatever) when one closes. Please download and try the new “DefaultEnterBehavior” branch once the new build comes up (should appear about 15-20 minutes after this message) and let me know your experience.
Wow. Works perfectly, as far I can ascertain. That functionality will a boon for when you are checking a bunch of GPs, prototypes, game pieces, etc and just need to close them when inspected. Coupled with ‘Open all contained pieces’ the solution is truly inspirational.
My thanks for your efforts in this space. Well done.
Buncha stuff on this line now merged into master, so available in all “master” SNAPSHOT builds, and will appear in 3.6.8. For reference the “Piece Definer” is the dialog with two listboxes where you add traits from the left side to the right side, or edit the existing traits of your piece on the right side.
Default dialog-closing button behaviors for Enter/Esc
Auto-select contents of Edit boxes when they get focus
Key shortcuts added to Piece Definer (see Game Piece help)
Piece Definer list boxes jump to entry starting with that letter
Key shortcuts added editing Layer trait (see Layer help)
Default dialog-closing button behaviors for Enter/Esc:
Overall this working beautifully in the editor. I’m less convinced about suddenly enabling it in the Player for Escape (especially). Self-interest declaration, I have found this a useful hotkey and I do use it. Maybe others do too. Rather than have the module users work out not to press escape to close a window in that module, could this be disabled in the player (maybe as a module global option)?
Enter doesn’t work for Notes, as the text box takes priority. However, Escape / Enter also do nothing for some other player windows - charts, maps, GPIW. If default Escape behaviour is enabled maybe it should close these, when in focus.
Auto-select contents of Edit boxes when they get focus
Working.
Key shortcuts added to Piece Definer (see Game Piece help) - I read that help and tried the Alt left/right arrow shortcuts. I couldn’t see that they did anything. Likely I don’t understand what I should be doing/seeing
Piece Definer list boxes jump to entry starting with that letter
Simple and working fine.
Key shortcuts added editing Layer trait (see Layer help)
The Alt+arrow and Alt+Enter keys work ok for me. It seems that the entire internet can’t identify an Insert key on a Mac keyboard and I can’t find a combo that works for Alt+Insert. Alt+ letter shortcuts can be problematic, as the following example shows:
Alt+N (rather Option+N on MacOS) misfired and overwrites a text field instead… (pressed when Description field was in focus):
Most text fields support Ctrl/Cmd+Z for undo/redo
Mostly working (nice!).
didn’t work in the Expression Builder
didn’t work when editing a Text Label field (in the player - does work in the chat window and the Notes editor)
Seems a little buggy though not in a major way… take a field where Cmd/Ctrl+Z is working: type 2 new characters at the end. Undo three times. Result: The new characters are undone, and on the third undo the entire field is erased. Seems wrong. Further UnDo restores the field, then repeated ones toggle blank/restore until it finally stops blanking. This last behaviour also shows up when you try other inserts/deletes/repeated undoes.
I don’t remember if Windows/Mac offer default hotkeys to change focus within the subwindows of an app. Maybe not? Obviously you could always click in the other window and then hit Enter.
Command-` on macOS to switch between Windows in the same application.
