RC - enhanced keyboard support NEARLY perfect (no Alt key anymore in Windows)

Now the extended keyboards (non US) work nearly perfectly.
Including the mac Alt/Option key being mapped to Windows AltGr key and allowing easy access to all windows-like keyboard composition.
Perfect.
Well, nearly.

Both Alt keys act as AltGr. So there is NO Alt key anymore.
Not even possible anymore to close a window using Alt-F4.
Not a show-stopper (I can click to close a window), but a real useability problem as things like Alt-E for Edit menu don't work either anymore.

If you could:
- pass the LEFT mac Alt as a PC Keyboard LEFT Alt
- pass the RIGHT mac Alt as a PC Keyboard RIGHT Alt (which is AltGr)
all without loosing anything else which you nicely fixed in RC1, then it would be superb for a RC2.

Thanks !!!

 

Make modifier mapping configurable

I'm repeating myself - please make this CONFIGURABLE! Hard-coded assumptions and enhancement tricks are always breaking something for some users.

For me, this new "enhanced" AltGr mapping IS a show stopper. I need Alt, and sacrifying it for AltGr wasn't even necessary - pressing Alt+Ctrl works the same as AltGR (in a VM as well as on a real PC).

 

Bad solution changing Option from ALT to AltGr!

Really bad - because that eliminates the ALT key alltogether, and selecting either the "right" or "left" key for the AltGr functionality will quite simply not work.

The MacBook Pro does not have a right ALT key. It only have one ALT/Option key, on the left. This is true for Swedish keyboard layouts at the very least.

Not having ALT in Windows is a showstopper for my company. We develop software - imagine the impact of not having this functionality, not being able to test keyboard shortcuts, not being able to switch between applications without a mouse while developing etc, etc, etc.

I am quite sure I am trying to kick in an open door here, though. I'm sure it'll be fixed soon enough - a hotfix would be really appreciated though, since this means I have to dig out that old Windows laptop again in order to do my work. But alas, that's life playing with beta software

::Ludvig A. Norin
HansaWorld Development
Sweden

 

Actually, for now it is a problem. For some unknown internal reason Max OSX does not know the difference between left and right modifiers. That is why it is difficult to do that, but we will try to fix this problem.

As a workaround you can

- Use 2 languages setup in your guest windows (English locale makes no difference between right and left shifts that is why right alt + f4 will work just fine. And you can switch to your locale to make use of AltGr.
So switching these locales will internally switch the meaning of the left/right alt key.

- Change the type of your guest operationg system to "Other" in VM configration - this will make left alt be left alt and use CTRL+ALT for AltGr. (ctrl+alt by default is used to "unlock" unput from the VM - so you will change this combination to something like ctrl+alt+shift)

 

Mac OS X can differentiate right and left modifiers!

That's what I thought for some time as well, but it's definitely not the case:

Just have a look at "System Preferences" "Dashboard & Exposé" - in the popups for keyboard shortcuts, left and right modifiers are listed separately! It even lists the FN modifier.

 

Apple developers say that:
"Back in Mac OS 9 days the virtual key codes and the left/right modifies were propagated all the way up to the application layers. But with the introduction of USB keyboards that didn't have direct mappings to our virtual key codes and didn't differentiate between the right and left modifiers it was decided to drop the prorogation of this information to applications."

That means that Dashboard & Expose config does use undocumented ways to do that, not awailable to api-users.

We will surely try to make it, but this little feature for apple-reasons is not that easy.

 

This is a good solution.

Having no key which maps to AltGr directly is NOT a problem, as long as some other trick (like ctrl+alt) can be used instead. I quickly tested it, it looks like it works flawlessly now. In my opinion, you should set this as the default in "Windows" type VMs (Alt is Alt and Ctrl-Alt is AltGr). At least the default should NOT be to have Alt -> AltGr and hence no Alt key. Even better, you should add a setting to the preferences to choose which key should map to AltGr. For instance, on an Apple extended keyboard, some people could like to map F13 (which doesn't exist on most Windows Keyboard) to AltGr.

Ideally, the per-VM setting would allow to choose what Mac Key or Key combination will be used for PC Alt, PC AltGR and PC 'Windows-key'.

I could set it very conveniently this way for instance:

Alt -> Alt
Apple-key -> AltGr
F13 -> Windows-key

Question: seeing that choosing Windows or Other as OS type in the VM configuration impatcs some keyboard mappings details, is there an exhaustive public list of all other settings / details that are affected in the VM depending on the OS type selected?

 

I understand that, but the current situation is not covering all problems.
I have to use Windows to establish a Citrix connection to a remote network where I'm running some X11 windows trough Exceed from a remote Unix system.
In this situation Exceed is doing its very own keyboard mapping and this only works for AltGr if a "real" AltGr scancode is received by Exceed. This is now no longer the case. Even if I had to klick on a screen symbol this would be better than what we have now - since there is no way besides copy and paste to get special chars like @ or | into these remote unix windows now.

How about supporting additional USB keyboards as an option? Today these are all captured by Mac OS X and there's no way to attach them to windows - or am I missing something?

Ingo