v3.5.1 - key command field not accepting Alt+2 (workaround)

Technical Support & Bugs
21

I have finally managed to get Vassal running under the Intellij debugger on a MacOS VM and using the Accessibility keyboard I can generate authentic key sequences. I am seeing the same sorts of errors you are reporting, so I should be able to move a bit quicker now.

I’ll organise an updated test build when I have made progress.

Regards.

22

Hi Mark,

A new snapshot will be available shortly.

This should fix issue 2 (Right Option key should be now be equivalent to Left Option key) and issue 4 (Ctrl-X sending ‘x’ to Chatter).

Issue 3 I could not reproduce. Could you check if this still happens in the new test build? Is the Hotkey you are using also used by any of the counters as a Command key?

Issue 1 is painful and I am investigating further, but I am not sure if I can do much about it. Those keys you are having trouble with are the ones that require 3 key presses to be converted to an accented character. When you press Alt-N, MacOS is waiting for you yo press the third key to generate the special character. Pressing Alt-N again causes the multi-press sequence to fail (as Alt-N-Alt is illegal) and for Alt-N to be used instead. So in fact, this appears to be standard MacOS behaviour.

There seems to be a way to turn this behaviour off globally. Open a Terminal window and type

defaults write -g ApplePressAndHoldEnabled -bool false

And restart Vassal and see if this changes things. It may be possible to turn this functionality off just for Vassal, but it looks like you need a bundle-id to do that (which you get if you publish in the Apple App Store).

Worst case, we may be able to turn it off globally when you start Vassal and back on when you leave vassal (if it was on before).

Thanks,
Brent.

23

Test build here: vassalengine.org/~uckelman/t … -macos.dmg

24

Thanks Brent and Joel. Snapshot test results…

Issue 1 - MacOS dead-keys - oh dear! I can see this is a can of worms. I am now thinking that the best thing might be to avoid using the Option key as a modifier key on its own (or with shift), or at least avoid the dead-key combinations (A,E,U,I,’). I will write more in a separate reply.

Issue 2 - Left/Right Option - Change of behaviour but not fixed. Left & Right Option now defines what I assume is the same keystroke, subsequently executing on a Left Option keystroke. Right-Option doesn’t do anything in the Player.

Issue 3 - Ignored Hotkeys - I wasn’t able to reproduce this either in this test version, but I can immediately do so if I go back to a different version. So whatever you did seems to have fixed this one.

Issue 4 - Ctrl+x chatter - fixed!

Mark

25

More on dead-keys and Option+key in general…

I have looked into the workaround and I wonder if you are confusing two methods of (mainly) accented character input that MacOS provides? I say this with the minimal experience of trying and failing to use the ApplePressAndHoldEnabled workaround and a few internet searches.

  1. Method 1 - dead-keys; this is the behaviour causing the immediate issue, just as you describe it. Press Option+N in a text field, get ~ press N again, ~ changes to ñ; and first of two presses seemingly ignored when used as a command keystroke.

  2. Method 2 - long press; press N for about a second; a menu pops up, offering a couple of options. One of the ways to select an option is to press a number beneath the option. In this case, 1 gives ñ, 2 gives ń. This happens in Vassal when the input focus is directly within the Chat input field but when elsewhere the normal text keys auto-repeat instead; I guess this is a side-effect / restriction of allowing text input when the user focus is elsewhere in Vassal from the Chat input field.

Based on the its name and my lack of success with the workaround, I think ApplePressAndHoldEnabled is controlling whether or not method 2 is enabled. I imagine that some apps might want to use key press duration for their own purpose hence the ability to disable; but Vassal? I guess not.

Method 1 on the other hand, dead-keys - when it shows up on an internet search in queries - the only useful looking response is to re-define the keyboard using ukulele to remove the dead-key functions. Not a viable solution for a module developer.

It looks like a minefield and not just due to dead-keys but also because of the more general dual role of the Option modifier for text and for application command. I took a look at GIMP to see how that program tackles the conflict. I find that it prioritises the text input function but allows use of the same key combination as a shortcut, and it does handle dead-key combinations. For example, in Gimp v2.10 on Mac, you can define Option+N and Option+M as Keyboard Shortcuts, say to open a recent file. The shortcuts work as expected except when in a text field, or on a panel where text input goes to a field on that panel (e.g in the panel that appears after selecting File…New… or when the Text tool is active).

Apart from the dead-key issue; there is the more general issue of Option+key’s role in text input:

When in the Chat text input field, Option+key generates text and triggers any hotkey function that may be defined. Whereas, elsewhere Option+key generates no text, only the Command keystroke function, if any.

I think if the chat input field is in focus, Option+key should generate text only, whilst remaining only a command modifier key elsewhere in Vassal.

Hope some of this helps. I thought it was interesting that GIMP handles the dead-key vs shortcut issue.

Mark

26

When used as a GamePiece command, or as a Hotkey (e.g. dice button) or both?

27

just HotKey, it turns out. GamePiece command works ok with both.