On 19 Nov 2018, at 21:49, Theo Markettos <theo@markettos.org.uk> wrote:
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Cheers
Tim
On Mon, Nov 19, 2018 at 07:43:18PM +0000, Timothy Coltman wrote:
Hello all
Please find attached a ZIP archive (169K) containing a patch for RPCEmu
0.9.1 that implements keyboard support for OS X/macOS. The file contains
a patch in unified diff format ("rpcemu-0.9.1-mac-v1.patch") plus a folder
("macosx") containing the icons for the Mac's dock. This should be
unpacked in the "src" folder and the patch applied from there.
That's great. It looked so good until I came across the Qt keyboard
problem, so fixing that should improve the RPCEmu Mac experience a lot.
4. The patch uses virtual key codes and assumes a UK keyboard layout.
There is support for other keyboard layouts, but needs these to be defined
in the "keyboard_macosx.c" file (there is a very basic French layout
defined that swaps "Y" and "Z").
I've had no end of problems with things getting keyboard layouts wrong on
MacOS (usually with remote connections to other machines where the other end
is set differently) so it wouldn't be the first time.
Does your layout handle US keyboards (it's usually \|~`#@" that get
into trouble)?
I'd imagine that most of the US keyboard layout will work, though I've not tried it myself. The code works by defining a base keyboard layout (UK) and you can add additional layouts to the code by telling it which keys are handled differently - so for French, for example, I've told it that "Y" and "Z" are different. It reads the current keyboard layout in when the application starts and goes from there (all in the "src/qt5/keyboard_macosx.c" file). It's probably not the best solution, but it does work. If there are keys on a US layout that are different, it would be trivial to add in the relevant mappings, whilst allowing other layouts to work unaffected. None of this would be needed if you could obtain scan codes from OS X, but you have do make do with virtual keys, handle modifiers separately and handle CAPS LOCK even more separately.
I usually use the 'British PC' layout on a Macbook Pro which is additional
fun because the keys are now moved around compared to the Apple layout.
Please note that there is no networking support. I did try and get it up
and running, using some of the code from the "Caliston" builds of Francis
Devereux and whilst it did look promising at one point (I could ping from
one end), I wasn't able to get it to work fully.
Those are my builds, and I never got networking to play nicely.
I wonder whether, instead of using TUN/TAP, on MacOS it might be worth
investigating NETunnelProvider as a native API for networking?
https://developer.apple.com/documentation/networkextension
That would make a much nicer user experience.
My hacked version would have been pretty awful, even if it had worked. Kernel extensions need to be signed in newer versions of OS X and I'm not a registered developer, so I ended up downloading an application called "Tunnelblick" and borrowing its Tun/Tap kernel extensions, which were signed. The emulator would randomly stall during !Boot when setting up networking, so I decided to cut my losses and gave it up as a bad job. I'll have a look at "networkextension", just to see, though I'm not too experienced when it comes to OS X development.
Any comments and suggestions would be appreciated. If anyone wants
binaries (so they don't have to compile), please let me know and I'll make
some available in due course.
Peter may have other opinions, but AIUI he doesn't have any means of
producing Mac builds. It sounds like you're set up to do that, so you could
take over producing them from me - I didn't have any special infrastructure
for that beyond a very hacked up Xcode with Snow Leopard libraries - I was
just making random builds on my laptop from time to time. (and running any
kind of CI with MacOS is a pain, so they're not straightforward to automate)
Peter did ask me whether I'd be prepared to create Mac binaries when I emailed him previously off-list, and I "umm"ed and "ah"ed about it. It really depends on how much work there is, and whether there are any other oddities thrown up by OS X that need to be worked around (such as the keyboard and networking). It would be nice to have a proper installer as well (there is an installer builder in QT apparently, though I've not investigated in any detail).
Theo
Cheers
Tim
No comments:
Post a Comment