Concerning the control/command keyboard shortcut option, thinking about the replies and giving some more thoughts as a Mac user, this is a bit long, so I hope it is helpful. I am not addressing any underlying technical drivers of the change, such as Brian referred to. Parts 1 & 2 of my contribution, will be moot, depending on the outcome against Part 3.
1) Why would a Mac user want this change? These are not game changing reasons but from the user viewpoint there are reasons worth considering, and that may be more significant than one might think…
a) It is commonplace for applications to follow the Apple style guide and give priority to the Command key in places that Windows would give it to the Control key. Speaking as a Mac user that has crossed from PC to Mac to PC and back again, you soon develop a, preference for command as a modifier key. Even though I have been using Vassal always on Mac, I still find myself occasionally going for the command key.
b) The most common Apple Mac keyboard is probably that found on the MacBook. It has two command keys and one (smaller) control key. Based on key size alone, it is 3x easier to use a Command+ combo than Control+ Even the Option key has more real-estate.
c) Some Mac users will not be so affected either way, if like me they tend to use the right-click drop-downs instead of shortcuts. In many game modules, I am not sure it makes much difference to efficiency (usually).
2. Legacy
The preference option should be for users to decide; the underlying purpose of the change is in doubt (as in fact, it is) if module developers feel the need to dictate the preference setting for their module. However, I can understand that it adds a complication to support - “OK, you’re using a Mac… now what is your preference for Command over Control?”. Hmmm… there is a conflict between flexibility/user acceptance and long-term support complications. Should there even be a Preference option and should it be permanent or a transition option to be removed after due warning?
The legacy option aside, the module will auto-configure to hint the relevant platform shortcut. Module documentation, at most, just needs to mention that Mac users can read “Control” as “Command” and vice-versa. At best, a list of key commands would include a column for Mac and other, but this is not necessary. Many Mac users will be well aware of the issue, as they have probably used apps on PCs as well. Is there something else that a module developer really needs to concern themselves about ? Apart from…
3. Key Conflict
This is where I started and it remains the main issue so far for me (along with other user-impact issues). Bdgza’s points about design from the ground up seem to broaden the issue, perhaps to a level that can’t be resolved in a point release, as in fact he argues, but for now I keep to the more obvious (to me) aspects.
As I tried using v3.3.3 during the course of yesterday it became apparent that this is even more of a problem that I thought. Command-keys were being passed through to the Vassal level, even if actioned by the module (apologies if this is just an issue with my module, as I don’t understand enough about what the system is doing to know what is expected behaviour or not). So for example, Command-H would apply a hit and, sure enough, hide the vassal window. Not helpful. And sorry, Brian, I agree with bdzga, “reprimanding” module developers (I’m being light-hearted) is not the way forward. As bdzga confirmed, Control/H will be very commonly used; it is logical that it would be - wargames produce Hits. If you consider for a moment the implications of changing this in one commonly used module, it is bad enough. Suddenly a key must change, and people who have been using that key for years must now remember to use a different one, and for what? That is a price too high (and that’s from a supporter of this change).
Now consider that a module developer shares the vision of this change and thinks about persuading their users to make the switch. But wait! That same community also uses 3+ other modules for a wargame in the same series. Naturally, though the modules have had different developers at different times, the developers have followed the same pattern, by design or by the magic of “H”, those other modules also use CTRL/H. So now the developer is going to ask the users to use a different key in one module in the series? Or is going to ask to change all the modules? One such series is Commands & Colors, a popular collection of modules. I won’t be pursuing that line.
It is very unlucky that Command-H is such a key conflict. The few others will only be apparent during module editing or are uncommon enough (probably) to be tolerable.
Which is why I came up with the “dumb” idea to displace the system level default for Command-H. Dumb it may be, but I got the idea from GIMP, which does it for Command-, . Looking at the idea dispassionately, it depends largely on how many Mac users have a habit of needing to hide their Vassal window with a key press (Vassal @ Work, maybe??!). Speaking only for myself, I didn’t even appreciate that that function was there, but then I tend to use the mouse and would hide windows that way. And it depends on whether those same Mac users would value the Command-key change more… because unless the change can address this key conflict then I do not think it is feasible. The value of the change diminishes rapidly as soon as significant modules in the catalogue actually require that users are in “legacy” mode. Speaking as one such user, I would not want to be changing my preferences between modules; it is one-time, all or nothing.
So here is my conclusion based on key conflicts alone, either
A) A solution to key conflict is found, at minimum to avoid the conflict with Command-H. Without a solution to this, a Preference option helps not a bit.
or
B) Accept that Vassal on Mac is indeed, again as bdgza suggests, a different world. Leave well alone, for now at least.
Option B is not so crazy as it might first seem to the dyed-in-the-wool Mac user. In fact, Vassal IS a different world. It is different from many applications because it allows the module developer free rein to re-define the operation of any and all keyboard press combinations. This is potentially far more intrusive than a common-or-garden app that might allow the user to (re)define some macro keys (incidentally, user-controlled, whereas Vassal modules are controlled by a third-party and effectively pre-defined once they reach the user). Maybe good practice for a module developer is to limit use of the Command key (ie META) and thereby reserve it to the Vassal level. This avoids such conflicts, on Mac at least. One nagging doubt; how have the other platforms avoided key conflicts like this, when Control is the preferred modifier on those platforms?
Thank you for reading, if you got this far.