Windows like performance

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.

1 Like

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.

Please install & try the “DefaultEnterBehavior” build at Builds of vassalengine/vassal

It does the ESC key too.

Downloading now. Off to bed soon, so report later.

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.

1 Like

Ctrl-Tab for Windows, IIRC.

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.

pressing enter will close each in turn.

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.

Yes, I also do this, as you say it is pretty much standard.

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.

1 Like