Page 1 of 2

Windows key as option key

Posted: Mon Nov 29, 2021 1:06 am
by dougg3
Hi there,

In both Basilisk II and SheepShaver, I've always liked being able to use the default key mapping of alt = command, windows = option so that it feels like a Mac keyboard. However, Windows takes over the Windows key and makes it pretty much impossible to use. Every time you press it and release it, the Start Menu pops up. And there are so many special shortcuts that use the Windows key. I know that there's an included keycodes file to move the keys around so you can avoid pressing the Windows key, but I'd prefer to just be able to use it instead.

So...I patched the code for both Basilisk II and SheepShaver to disable Windows' normal functionality of the Windows key when they have keyboard focus, so that they handle the keypress and hide it from Windows. It's in my test branch (which was branched from kanjitalk755's branch):

https://github.com/dougg3/macemu/tree/windows_key

Before trying to get this merged, I thought it would be useful to get some more feedback. I already know of one person who says this will break their workflow because they like being able to press the Windows key intentionally to give control back to Windows. I can see how this would be useful, especially if you run it full screen. I think it would be pretty straightforward to add this new functionality as a setting in the _prefs file. Maybe it could be a checkbox named something like "Intercept Windows key presses" in the Keyboard/Mouse section of the BasiliskIIGUI/SheepShaverGUI programs? Anybody have any great ideas on how this should be done correctly? I don't want to break anybody's workflow but I also want to get this functionality merged so everyone else can use it if they want to. Thanks!

Re: Windows key as option key

Posted: Sun Jan 09, 2022 8:10 pm
by dougg3
I finished implementing this. It's a new boolean option in the prefs file called "reservewindowskey", along with a new checkbox in the Keyboard/Mouse tab of the setup GUI called "Reserve Windows Key". If you enable this option, Basilisk/SheepShaver will prevent the Windows key from doing normal Windows shortcuts, as well as opening/closing the start menu. So you can use it as the option key and it will feel just like a Mac keyboard.

I submitted a pull request to the kanjitalk755 GitHub repo. We'll see how it goes!

https://github.com/kanjitalk755/macemu/pull/110

Re: Windows key as option key

Posted: Mon Jan 10, 2022 8:58 am
by Ronald P. Regensburg
I will need to adjust the current keycodes files. They are not compatible with this new feature.

I have no Windows machine or keyboard to try it. Does it work without swapping option and command keys? Normally, with a Windows keyboard and without keycodes file, and without swap_opt_cmd enabled, the Windows (Logo) key is mapped to the Command (Logo) key in the emulator and the Alt key is mapped to the Option key in de emulator.

Re: Windows key as option key

Posted: Mon Jan 10, 2022 4:30 pm
by Cat_7
With my Ansi keyboardtype 2, this works without keycodes file and swap_opt_cmd true

Best,
Cat_7

Re: Windows key as option key

Posted: Tue Jan 11, 2022 12:36 am
by dougg3
I haven't played around with the keycodes file too much, but this functionality should be compatible with whatever keycodes configuration you throw at it. I didn't change anything about the way that SDL handles the keys, so whatever you have mapped in your keycodes file should still work fine. The only change is that the windows key is now usable, whereas previously, Windows would pop up the start menu and cause all kinds of interference.

My experience is that the default behavior without a keycodes file, no swap_opt_cmd, and keyboardtype 5 is: Windows key = option, Alt = Command.

Re: Windows key as option key

Posted: Tue Jan 11, 2022 10:04 am
by Ronald P. Regensburg
In the current keycodes files for the SDL2 BasiliskII and SheepShaver builds I changed the mapping of modifier keys on a Windows host such that all Mac modifier keys can be used in the emulator without using the Windows keys. I will undo that in keycodes files for newer Windows BasiliskII and SheepShaver builds that can use reservewindowskey.

Re: Windows key as option key

Posted: Wed Jan 12, 2022 3:40 am
by dougg3
Ahh, I understand now. I would be happy to do any testing you need help with!

Re: Windows key as option key

Posted: Fri Jan 14, 2022 8:50 am
by Ronald P. Regensburg
These new keycodes files should work with any January 2022 or later SDL2 SheepShaver or BasiliskII build from kanjitalk755/macemu source, for Windows builds provided "reservewindowskey" is true: http://ronaldpr.home.xs4all.nl/keycodes ... y_2022.zip

Re: Windows key as option key

Posted: Sun Jan 16, 2022 12:54 am
by dougg3
I did some testing. The keycodes included with the latest January 10th, 2022 build (https://surfdrive.surf.nl/files/index.p ... E/download) seem to work fine in Windows.

The keycodes in the Keycodes_January_2022.zip file don't seem to work properly for me. Both the Windows key and the Alt key act as the Option key. I couldn't find a way to activate the Command key.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 12:23 pm
by Ronald P. Regensburg
dougg3 wrote: Sun Jan 16, 2022 12:54 am I did some testing. The keycodes included with the latest January 10th, 2022 build (https://surfdrive.surf.nl/files/index.p ... E/download) seem to work fine in Windows.
That is odd. I would expect that keycodes file to direct both keys to Option if swap_opt_cmd is true and both keys to command if swap_opt_cmd is false (plus the left control key to command respectively option).

And I would expect the January 2020 keycodes files to behave as expected, with positions of command and option depending on swap_opt_cmd true or false.

Are you sure you did not accidentally swap the keycodes file versions?

Re: Windows key as option key

Posted: Sun Jan 16, 2022 1:21 pm
by Ronald P. Regensburg
From a previous discussion with kanjitalk755 I recall that swap_opt_cmd is forced to false when a valid keycodes file is used. That feature should be removed now that reservewindowskey is available.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 6:25 pm
by emendelson
Question about the latest code:

What settings do I need in the prefs file if I want to run BII under Windows with the Windows-system key on the left matching the System 7 key on the right, and with the current keycodes file loaded:

Alt = Option
Ctrl = Ctrl
Win = Cmd

Will be grateful for any clear guidance!

Re: Windows key as option key

Posted: Sun Jan 16, 2022 7:37 pm
by Ronald P. Regensburg
Do you mean with or without a keycodes file?
What do you mean with the "System 7 key"? The command key?
With the latest changes, with the Windows keys useable, there should be no difference anymore between the keys on the left and the keys on the right.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 8:19 pm
by Ronald P. Regensburg
There should be a new checkbox in the GUI to reserve the Windows key (not sure how it is named exactly in the GUI). If checked, an item reservewindowskey true will be added to the prefs file. Of course you can also add the line to the prefs file in a text editor.

If these lines are in the prefs file:

Code: Select all

reservewindowskey true
swap_opt_cmd false
keycodes false
The key order should be:
Left Control --> Control
Left Windows --> Command
Left Alt --> Option
-
Right Alt --> Option (or Control-Option)
Right Windows --> Command
Right Control --> Control

If

Code: Select all

reservewindowskey true
swap_opt_cmd true
keycodes false
The behaviour of Windows and Alt keys will be swapped, thus providing the keys in the same order as on a Mac keyboard.

With the use of a compatible keycodes file the behaviour should now be the same as without a keycodes file.
Only swap_opt_cmd true may not work because earlier it was made such in the source code that swap_opt_cmd is forced to false when a valid keycodes file is used. If still present, that feature should best be removed now.

I tried to make a new keycodes file that is compatible with the reservewindowskey feature: http://ronaldpr.home.xs4all.nl/keycodes ... y_2022.zip
It is not fully tested yet.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 9:12 pm
by emendelson
Thank you! That works for both SheepShaver and BasiliskII, built from the latest code. I won't update my Windows-based systems until the code is updated in the way you described.

This is a major improvement in the Windows setup. Thanks again to everyone involved.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 9:30 pm
by dougg3
Ronald P. Regensburg wrote: Sun Jan 16, 2022 12:23 pm Are you sure you did not accidentally swap the keycodes file versions?
It's always possible that I screwed something up. I will do a more in-depth test now, starting from a fresh copy of BasiliskII-Windows-10-01-2022.zip:

Code: Select all

$ md5sum keycodes BasiliskII_keycodes
697babfe6e1e8659ed4c3dead3f20dc3 *keycodes
697babfe6e1e8659ed4c3dead3f20dc3 *BasiliskII_keycodes
I have a US keyboard. Here are the relevant lines from my BasiliskII_prefs file (so for the first test, no keycodes file being used at all):

Code: Select all

keyboardtype 5
keycodes false
reservewindowskey true
Results:
  • Left Windows = Option
  • Right Windows = Option
  • Left Alt = Command
  • Right Alt = Command
  • Left Control = Option
  • Right Control = Control
Now, for the rest of these tests, keycodes is set to true:

Same results as above

Adding "swap_opt_cmd true":

Same results as above

Adding "swap_opt_cmd false":
  • Left Windows = Command
  • Right Windows = Command
  • Left Alt = Command
  • Right Alt = Command
  • Left Control = Option
  • Right Control = Control
Okay, now I'm swapping out with the newest keycodes from Ronald (Keycodes_January_2022) and repeating this experiment:

Code: Select all

$ md5sum keycodes BasiliskII_keycodes
915e79337ebf252478d4d1074152671d *keycodes
915e79337ebf252478d4d1074152671d *BasiliskII_keycodes
keycodes true, swap_opt_cmd missing from file:
  • Left Windows = Option
  • Right Windows = Option
  • Left Alt = Option
  • Right Alt = Option
  • Left Control = Control
  • Right Control = Control
It appears there is no key mapped to Command now, but it does fix the left control key.

Adding "swap_opt_cmd true":

Same results as above

Adding "swap_opt_cmd false":
  • Left Windows = Command
  • Right Windows = Command
  • Left Alt = Option
  • Right Alt = Option
  • Left Control = Control
  • Right Control = Control
Conclusion:

Without a keycodes file, or with the default one provided in the latest Basilisk zip file, it mostly works correctly, except when swap_opt_cmd is set to false.

With the new keycodes file, there is no way to use the command key except by setting swap_opt_cmd to false, in which case it works exactly as intended.

Interesting...I was hoping my tests would resolve my confusion, but I think I'm more confused now.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 10:06 pm
by Ronald P. Regensburg
dougg3 wrote: Sun Jan 16, 2022 9:30 pmbut I think I'm more confused now.
And so am I.

Different people, you, emendelson, and Cat_7, reporting different results. (There are also tests by Cat_7 discussed in PMs)

BTW: If you use a US keyboard, that will probably be an ANSI keyboard. It will not make a difference with these keys, but keyboardtype 2 will show an ANSI keyboard layout in Key Caps.

Bedtime for me now. I will have another look at this later.

Re: Windows key as option key

Posted: Sun Jan 16, 2022 10:15 pm
by Ronald P. Regensburg
In your commit, did you make more changes than just reserve the Windows key for the emulator?

Re: Windows key as option key

Posted: Sun Jan 16, 2022 10:46 pm
by dougg3
Not intentionally anyway :-) I will do more testing with older builds to make sure my commit didn’t break it. I will also investigate the code that deals with the keycodes in more depth to try to understand what is going on.

Re: Windows key as option key

Posted: Mon Jan 17, 2022 12:17 am
by dougg3
There are a lot of variables here because the September 2021 keycodes are different from the January 2022 keycodes which are different from the newest keycodes from this thread. For the sake of simplicity, I'm ignoring the keycodes file that came with the September 2021 binary. Here are a bunch of tests of the last two revisions of Basilisk II:

Test 1

Code: Select all

keyboardtype 5
keycodes false
reservewindowskey true
September 2021: Ctrl = Ctrl, Windows = Option, Alt = Command
January 2022: Same. This doesn't match the results I wrote earlier. I think I screwed up my test with keycodes = false last time because I had two "keycodes =" lines. My bad.

Test 2a

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
using stock keycodes bundled with Jan. 2022 Basilisk (697babfe6e1e8659ed4c3dead3f20dc3)
September 2021: Left Ctrl = Option, Right Ctrl = Ctrl, Windows = Option, Alt = Command
January 2022: Same.

Test 3a

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
swap_opt_cmd true
using stock keycodes bundled with Jan. 2022 Basilisk (697babfe6e1e8659ed4c3dead3f20dc3)
Same results as Test 2a on both binaries.

Test 4a

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
swap_opt_cmd false
using stock keycodes bundled with Jan. 2022 Basilisk (697babfe6e1e8659ed4c3dead3f20dc3)
September 2021: Left Ctrl = Option, Right Ctrl = Ctrl, Windows = Command, Alt = Command
January 2022: Same.

Test 2b

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
using newest keycodes (915e79337ebf252478d4d1074152671d)
September 2021: Ctrl = Ctrl, Windows = Command, Alt = Option
January 2022: Ctrl = Ctrl, Windows = Option, Alt = Option something in the new version screwed this up?

Test 3b

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
swap_opt_cmd true
using newest keycodes (915e79337ebf252478d4d1074152671d)
Same results as test 2b on both binaries.

Test 4b

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey true
swap_opt_cmd false
using newest keycodes (915e79337ebf252478d4d1074152671d)
September 2021: Ctrl = Ctrl, Windows = Command, Alt = Option
January 2022: Same.

Summary

The latest January 2022 binary behaves the same as the previous September 2021 binary, with one exception. With swap_opt_cmd true (or missing) and using the newest key mappings, something is screwed up that causes the command key to not work like it should.

One last test: test 2c

Code: Select all

keyboardtype 5
keycodes true
reservewindowskey false
using newest keycodes (915e79337ebf252478d4d1074152671d)
September 2021: Ctrl = Ctrl, Windows = Command, Alt = Option
January 2022: Same.

Conclusion

Clearly, something is wrong with the way reservewindowskey is implemented. It is occasionally changing the key mappings when it's enabled. I will revisit the code to understand why it's not working as it should.

Re: Windows key as option key

Posted: Mon Jan 17, 2022 1:51 am
by dougg3
Okay, I figured it out. There's a piece of code that intercepts the press of the Windows key, prevents it from being passed onto the rest of the OS, and creates an "emulated" SDL key event to let the normal key handling code in Basilisk/SheepShaver know that the key was pressed. In that emulated event, I filled in the keycode, but not the scan code. Some of the existing code looks at the scan code instead of the keycode, and it was getting confused.

https://github.com/dougg3/macemu/commit ... 62535e5880

With this change implemented, all of the test cases match the behavior I documented above for the September 2021 build. I'll wait a bit to hear what you guys think about all the tests I performed, and then I'll submit a pull request to kanjitalk755 for this bug fix.
Ronald P. Regensburg wrote: Sun Jan 16, 2022 1:21 pm From a previous discussion with kanjitalk755 I recall that swap_opt_cmd is forced to false when a valid keycodes file is used. That feature should be removed now that reservewindowskey is available.
I see a commit where that is discussed. It does seem based on my tests above that it's impossible to get Windows = Option when a keycodes file is being used.

Re: Windows key as option key

Posted: Mon Jan 17, 2022 9:43 am
by Ronald P. Regensburg
1. I am not sure what you did. As far as I can tell, the only thing that needed to be changed with applying the reservewindowskey feature was making the Windows key available to the emulator. No messing with scancodes and keycodes. If the Windows key press was blocked somewhere in the code, that should have been solved there.

Anyway, the default behaviour of the Windows keys (that is with swap_opt_cmd false) should be to activate the Command key in the emulator. If you want the keys in the same order as on a Mac keyboard, you use swap_opt_cmd true, which is, I think, the default in Windows and Linux hosts.

The SDL2 scancode for the Windows keys are 227 and 231, the same as the SDL2 scancodes for the Command keys. Both are the so called "Logo" keys.
The SDL2 scancode for the ALT keys are 226 and 230, the same as the SDL2 scancodes for the Option keys.

From left to right on a Windows keyboard:
Control - Logo - Alt - space - Alt - Logo - Control
and on a Mac keyboard:
Control - Alt - Logo - space - Logo - Alt - Control

Note that these are properties of the keyboards, not of the OS.

swap_opt_cmd true will swap the option and command keys in the emulator to get the order of the keys that is usual on a Mac keyboard while using a Windows keyboard.

2. I am only interested in tests without a keycodes file and with the January 2022 keycodes files. All other keycodes files were specifically edited to be able to avoid the Windows key and should be incompatible with reservewindowskey. (All keycodes files for SDL2 builds from kanjitalk755 source were created by me.)

Code: Select all

keycodes false
reservewindowskey true
swap_opt_cmd false

Code: Select all

keycodes false
reservewindowskey true
swap_opt_cmd true

Code: Select all

keycodes true
reservewindowskey true
swap_opt_cmd false

Code: Select all

keycodes true
reservewindowskey true
swap_opt_cmd true
3. Maybe a superfluous remark, but the configuration cannot be changed while the emulator is running. A new start is needed after making changes.

4. With keycodes true BasiliskII and SheepShaver will automatically pick an available keycodes file if no path is (clearly) defined, so make sure only the keycodes to be tested is available.

5. I did not check if this is still so, but swap_opt_cmd is forced to false if keycodes is set to true. This made the alternative keycodes files possible. With swap_opt_cmd true those keycodes were pretty much unusable.

If this is still so, the combination

Code: Select all

keycodes true
reservewindowskey true
swap_opt_cmd true
cannot be tested.


Edit: I corrected incorrect "Control" where I should have written "Command" and added explanation about the order of keys on keyboards.

Re: Windows key as option key

Posted: Mon Jan 17, 2022 5:19 pm
by dougg3
Ronald P. Regensburg wrote: Mon Jan 17, 2022 9:43 am 1. I am not sure what you did. As far as I can tell, the only thing that needed to be changed with applying the reservewindowskey feature was making the Windows key available to the emulator.
That is correct, and that is all that I actually changed. However, I made a mistake when I did it. I only provided one of the two pieces of data that the emulator needed. The code in Basilisk/SheepShaver that takes the keypress and decides what key it should actually be mapped to (based on the keycodes file) uses both "keysym.sym" and "keysym.scancode" from the SDL2 key event. I was only filling in "keysym.sym", so the SDL event I was creating was incomplete. This explains the discrepancy I was seeing in my test results between the newest build and the previous build. Ever since I fixed that, my test results are identical to the September build in all configurations.
Ronald P. Regensburg wrote: Mon Jan 17, 2022 9:43 am I am only interested in tests without a keycodes file and with the January 2022 keycodes files.
Sounds good. I will run all of these tests with my bug fix code below. Thank you for laying them out!

Code: Select all

keycodes false
reservewindowskey true
swap_opt_cmd false
Ctrl = Ctrl, Windows = Command, Alt = Option. Looks correct to me.

Code: Select all

keycodes false
reservewindowskey true
swap_opt_cmd true
Ctrl = Ctrl, Windows = Option, Alt = Command. Looks correct to me.

Code: Select all

keycodes true
reservewindowskey true
swap_opt_cmd false
Ctrl = Ctrl, Windows = Command, Alt = Option. Looks correct to me.

Code: Select all

keycodes true
reservewindowskey true
swap_opt_cmd true
Ctrl = Ctrl, Windows = Command, Alt = Option. This is currently broken, because as you pointed out, swap_opt_cmd is being forced to false when keycodes are being used.

Okay, whew. Things are starting to make sense again.
Ronald P. Regensburg wrote: Mon Jan 17, 2022 9:43 am Maybe a superfluous remark, but the configuration cannot be changed while the emulator is running. A new start is needed after making changes.
With keycodes true BasiliskII and SheepShaver will automatically pick an available keycodes file if no path is (clearly) defined, so make sure only the keycodes to be tested is available.
Correct, I have been following all of these steps while testing.
Ronald P. Regensburg wrote: Mon Jan 17, 2022 9:43 am If this is still so, the combination ... cannot be tested.
That matches what I'm seeing. It should be possible to take out the "force swap_opt_cmd to false when valid keycodes are used" logic, but my only question is: what about Linux? "reservewindowskey" has no effect on Linux. Does Linux depend on the ability to force swap_opt_cmd to false when keycodes are enabled? Or will we be safe just changing this across the board?

Re: Windows key as option key

Posted: Mon Jan 17, 2022 5:54 pm
by Ronald P. Regensburg
Great!

I suppose you will contact kanjitalk755 about the correction in your commit?

Shall I contact him about removing force swap_opt_cmd to false when a keycodes file is used? It is not needed anymore with reservewindowskey and the new keycodes files.
Does Linux depend on the ability to force swap_opt_cmd to false when keycodes are enabled? Or will we be safe just changing this across the board?
I am not sure if this is used for all hosts. If it is, it is best removed for all. It was especially important for Windows because of the specific keycodes files, but macOS may also be used with a Windows keyboard (or other non-Mac keyboard) and Linux may be run on different kind of machines and different keyboards.

Maybe swap_opt_cmd false should be the default setting on macOS and swap_opt_cmd true should be the default setting on Windows and Linux.

Re: Windows key as option key

Posted: Mon Jan 17, 2022 6:05 pm
by dougg3
Ronald P. Regensburg wrote: Mon Jan 17, 2022 5:54 pm I suppose you will contact kanjitalk755 about the correction in your commit?
Yep! I already sent a pull request with my bug fix.
Ronald P. Regensburg wrote: Mon Jan 17, 2022 5:54 pm Shall I contact him about removing force swap_opt_cmd to false when a keycodes file is used? It is not needed anymore with reservewindowskey and the new keycodes files.
Sure, that would be great! I would do it myself, but I'm not familiar enough with the history of swap_opt_cmd so I think it would be better for you and kanjitalk777 to figure out that change.

Thank you so much for all of your help with testing and knowledge provided. I'm glad we were able to track down a problem and fix it. I think this is going to make the user experience on Windows a lot better! I'm excited about it.