While in an antagonistic mode. I also cannot speak for other OS’s.
The vast majority of windows applications accept the ‘enter’ key press as acceptance of the ‘OK’ button for the various pop-up windows/dialogues/etc.
Vassal is the exact reverse. Even tabbing to the OK button and pressing enter does not work. You have to press the space bar.
Can we please at least try to emulate the windows default default press of the enter key.
1 Like
Would you give a specific example of a dialog in Vassal which is like this?
There’s another couple of examples of where you can help us with V4 development, UI guidelines and quality control.
With V3, that boat may have long sailed. Don’t forget, this is a piece of software who’s gui was mostly locked in stone on Windows 95 in a 25 year old gui framework.
Could you give some specific examples? I just tried the first example I found (Selecting close game on an unsaved game), and Enter worked just fine to fire off the default selected Yes button, So it may just be a probem with some custom dialogs.
Lets see. Most if not all game piece traits, GPs, map windows/boards, boards, zones (will not even move out of the location format using tab key), chart window menu, tabbed panels, scrollable lists, pull down menus.
Appreciate that V3 is obsolescent. Still very much usable though. My opinion, for what that is worth, is that V3 should only be looked at if there is a reported bug. No new features, etc - just bug fixes.
Has been a long since I got some training in software quality control/debugging, like around 30+ years ago. I feel that my best way to help is with the documentation. Documenting stuff always seems to lag behind. Software developers want to develop software, engineers want to build, etc. No one wants to document the system, as it’s a bugger to do that.
Perhaps V4 can keep a lot of the V3 documentation. The changes in how things happen is at the software level. Users/module developers only need to informed of what they do, not how it is done. There may be some new ways of doing some things though that are different from V3. For ex having a ‘table/container’ for all GPs. Having a right click command to ‘open all contained pieces’ (I really hate having to double click on many 10’s of pieces so I can review each one).
Which dialogs for these things? In the editor? In the player?
Pick one and describe exactly how to reach it.
OK, I’m beginning to question the knowledge of the system from those that support it. All the cited dialogues are only available when in edit mode. No player of a module has access to these dialogues unless they are in edit mode.
Grab a module, any module, open in edit mode and open a GP, or create a new GP. Go to ‘Game Piece Palette’, expand as necessary and open a game piece, open any trait for that game piece. Double click on a ‘Map Window’, (developers’ actual name immaterial). In any of these:
- Do something with a field.
- Press Enter.
- Following the total lack of dialogue closure (and acceptance of the change), now press the ‘tab’ key until the ‘OK’ button is active/highlighted. Press enter.
- Still no joy, press the space bar.
Is that of sufficient clarity?
I won’t go hunting for problems—it’s not a good use of my time. Anyone reporting a problem that’s reproducible ought to give a description sufficient to eliminate any doubt about how to reproduce it.
Thank you for providing such a description.
3 Likes
If I could try to offer some additional clarity that may help. Easton mentioned that the GUI API basically stopped moving forward around the timeframe of Win95. The further out from there time progresses, the more detached from modern standards the API becomes. If the API offers no mechanism for the behavior that you want (current windows behavior) then there may be nothing that can be done about it. This is, in part why everyone is looking forward to V4. Incidentally, I took a photo of the Java Swing GUI API with the abstract/concrete filter so you could see it…you will notice that those are indeed windows, but they are not the windows you are accustomed to… 
1 Like
Understand fully. Cannot raise a dead dog, not matter how not dead it looks.
I opened the trait dialog on a game piece.
The dialog shouldn’t close at #2 because the Ok button won’t have focus, and does not. At #3, after having brought focus to the Ok button, Enter closes the dialog for me on Linux.
What OS are you using?
Swing does appear support the use of Enter to activate a button when that button is currently highlighted/has the focus.
There is also a big difference between a simple message dialog box with 2 or 3 buttons and a complex information gathering ‘dialog’ containing multiple input fields, when closing the dialog on hitting Enter is not appropriate.
Simple dialogs are often created with the Yes or Accept button already selected, so all you have to do is press enter to accept it.
Whatever it is, stop using it and use Linux. It will change your life. 
Also, this does raise the question: “why would we follow Windows UI choices? It’s been junk since Win7”.
This is rhetorical, no one needs to answer. 
1 Like
Oh just forget it all. I, and many others, use windoze. If you use another OS then the response will be different. Just forget about the windoze users. We are irrelevant.
Sorry, I should have said “trigger warning.” 
Well, that’s really the answer. We use win conventions because so many people are accustomed to them.
It’s the same reason Apple inverts the scroll-wheel. Because they want their users to feel frustrated if they ever use a windows computer.
1 Like
I, and many others, use windoze. I, and I hope some of the many others, would like to press the enter key on doing something in a pop-up window and having that something done and window closes.
Swing this , swing that is so totally irrelevant, from a windoze user’s perspective.
Use a windoze PC and do what I asked. Then may perspective prevail.
I want a test based on an ‘orange’, not a test based on a banana.
It’s worse on Mac because a button can’t get “focus”. So you can’t even press it with spacebar. VASSAL is completely mouse-only.
So what’s the expected behavior on MacOS?
Really. Well we do indeed learn something new every day.
One dialog button is marked (by the developer) as the default button and activates with the Enter/Return key. One button is marked as the cancel button and activates with the Escape key.
There are special cases for dialogs where a Command+letter hotkey (ime the first letter of the button caption in English) will trigger a button when there are 3 buttons or other special circumstances. If the dialog contains a multiline textfield with focus then the Enter/Return key would be double booked, but it’s not usual for a dialog to have a multiline textfield, it’d usually be a window, and windows can use menuitem commands.
2 Likes
This isn’t intended to be churlish—it’s a matter I find genuinely perplexing. Dialogs not conforming to OS-specific behavior is something that’s likely to have been the case the entire time Vassal has existed, and could I’m sure be traced back even further to when VASL was the main application. I think it’s safe to say that things have been this way for over 25 years now.
Why is this first being noted now in 2022 instead of, say, 2006, at a time when we would have eagerly sunk resources into fixing it?
My own contribution to fixing this is V4. I’ll review a PR for fixing this in V3 if someone else makes one.
2 Likes