I hope that this is not already asked. I looked at the sourceforge site and i have not find it.
Today i was struggling with Trigger action. One of them was “firing” a keystroke 10 times. By chance, that keystroke was the same of one in my dual monitor manager, the one that enable/disable the secondary monitor… so my whole desktop was resized 10 times and my 2nd monitor switched from “standby” to “on” 10 times… it WAS an old CRT. Yes, it WAS. That last events have burned something inside, and it is now permanent black
So, i’ve discovered that Vassal fires keystrokes to the OS just to have them back… hoping that no one will trap that particular keystroke.
I’m a programmer, but i’ve never seen a line of code of Java, so what i’m asking may be impossible… anyway:
I’d like to see the keystrokes replaced by “internal” events. Suppose that i’m doing the moves for my counter: in my dreams, i write somewhat like #event_move_up# instead of CTRL UP, and then i can use that event name everywhere.
Now imagine to go in a “event table”: you now can see all the declared events, and you can now assign a keystroke to the one that really needs one. Some events may be only “internal” and you may not want let the user to fire them with some keys.
More, if the Keystroke → EventName association is tied to a language, it will be possible to tie the (imaginery) #Jump_Event# to CTRL J for english and CTRL S for italians (jump = salta…)
So you can plan all your keys in a “organized” manner…
More, you’ll have virtually an infinite number of possible events: right now, in the module i’m designing, i’m in a sortage of keys: if i want to keep them organized in a “logic layout” i have to find what keys of my italian keyboard are not accepted, what keys defined with an english designer are not usable (CTRL ] or [ are not usable for me, as example)… think at a user with a laptop (so without a pratical numpad)…
And maybe Vassal will stop to burn my old, trusted CRTs
This feature is already included in the upcoming version 3.2 of Vassal. It is called ‘Named Key Strokes’. It works exactly as you describe, for any keystroke, you can press a single keystroke, or keep typing and enter a name.
Wow, I think that’s the first time any software I’ve worked on has
destroyed hardware. Sorry about letting out your monitor’s magic
smoke!
What Brent said is correct—in 3.1 and earlier, triggers send real
keystrokes. From 3.2 onward, they won’t do that anymore. I’m rather
surprised to hear that the keystrokes escape from VASSAL, actually.
I had supposed that they were all trapped by the JVM and never made
it to the OS itself.
I’m happy to see that improvement. Working only by keystrokes is really a strong “limit”, imho.
OS and “desktop ambients” are no more an “exact science”… at least Windows
I like a lot some tiny programs that “take cares” of your windows / desktop (s), snapping them, swapping them and so on.
So I’ve found that each one has its own method to “steal” keystrokes, mouse clicks and movements, and sometime they fight alot with the others programs just 'cause the developers did not think that some “private” events may have been stolen and modified… not to talk about ObjectDock-like programs.
So maybe JVM was supposed to keep keystrokes inside, but my multimonitor program acted at a lower level… i really dunno.
My window manager on Linux has a ton of hotkeys, so there’s lots of potential
for hotkey collision, but I’ve never seen a bad interaction like that myself.
It makes me think that these keystrokes don’t escape from VASSAL on Linux.
I don’t think of the keystrokes as “escaping” from VASSAL, but rather
being intercepted before they even get there. I can see the OS
intercepting keystrokes with something in the keyboard driver software
before the keystrokes ever get passed on to applications.
There are some good reasons to have that happen. For example, it’s
sometimes nice to have a keystroke that will always get to the OS in
spite of intervening programs. I’m thinking of something like ^Z or
^C in Unix, which – if it were intercepted by the program first –
would make programs that are off-the-rails uninterruptible. I think
the Ctrl-Alt-Delete sequence in Windows is also handled with priority
by the OS in order to enhance security for login.
It also stops applications from disabling certain OS functions that
people might like – like screen capture keystrokes.
So it doesn’t surprise me that certain keystrokes can’t make it
through to the application. But I do think that this intercepting
does sometimes go a bit too far. For example, on the Mac, the screen
control (Expose) keystrokes have priority handling. They are user
configurable, so they do have the potential to interfere with other
software. (They have also interfered with software written before
Expose was added with its default keystrokes).
