Split from #425.
With windows machine alt+(numbers) allows typing of non-English characters, such as alt+(0241) = ñ.
See [http://en.wikipedia.org/wiki/Unicode_input] - this is platform dependent and the default X11 input method does not provide a way of entering unicode via numeric values.
See also: GTK+ is an ISO 14755-conformant system. The beginning sequence is Ctrl+⇧ Shift+U and the ending sequence is ↵ Enter or Space. Programs based on GTK+, such as GNOME applications, support Unicode input. - this is no good for us unless we can change the beginning sequence...
This may well require the development/enhancement of an X11 input method to be able to emulate the client's behaviour on the server.
Note: this would need to be enabled for win32 clients only, OSX and Linux clients will be expecting a different behaviour..
the gtk input method selection context dialog
Some related changes in #634.
afarr: it would be worth trying various input methods to see if one can be made to behave more similarly to what windows users expect. If so, maybe we can modify it to emulate windows unicode input, instead of having to create a custom input method.
You can test by installing all the input method packages on your server (all of
immodules, etc). More information here: archlinux: Internationalization Input methods in Xorg
Then the easiest thing is to use the test app test_form_input.py and change the settings as per this screenshot:
It should be tested without xpra first, as keyboard state issues may hinder testing (and we can fix that separately).
Trying to test with windows client 0.15.0-r7376, I couldn't find any sign of the test_form_input.py as a .pyd in the Xpra directory (all the other files were .pyd).
Likewise, spelunking through the fedora 20 0.15.0-r7376 server I couldn't find any sign of the xpra directory in the site-packages directory, where I usually find python and gtk and such utilities.
Downloading the test_form_input.py and installing it into the Windows Xpra directory, and then trying to run it with the
Python_execfile as an argument seems to fail. (I'll enclose a screenshot.) ... as a wild clutch at straws I also tried going to
http://xpra.org/trac/browser/xpra/trunk/src/tests/xpra/test_apps/test_form_input.pyd ... needless to say, your trac system laughed at me for that.
ticket 572 test_form_input_py run fail
Tests are not bundled with the software, which is why you have to download it via the link provided.
You are trying to test X11 input methods, not mswindows ones, so you have to run this test script from an X11 environment (Fedora or other).
I'll be hijacking this one for now(now that I'm settled in Switzerland)...
Anyways. On to the meat of this:
Alternate to using the X11 method using
Control + Shift + U there is another way using the built-in compose key from
or if you like Wikipedia
äis inputted by holding down
If we want to emulate the windows input method we can change the
compose key code using this method http://alec.mooo.com/xcompose.html with the proper key from terminal input on detecting a Windows client.
altor another key, we stop looking at character inputs and watch for the Windows codes. But that would probably unnecessarily messy.
I'll look into setting this up on our Fedora 20 test environment sometime Monday. In the meantime I have gotten it to work in my Linuxmint install locally.
I hope this helps and I didn't totally misinterpret the meaning of the last few comments.(If I did let me know!)
We don't want to use the compose key, windows (and osx) users expect the keyboard to behave as if the application was running locally (as far as they are concerned, it is!). Which means using an input method, so we want to find the one that behaves closest to the win32 (and later osx) one. We may even have to modify it to change the start sequence.
Note for implementation if we get around to it: we may want to make this conditional upon the client side im settings, so that we don't enable it if the user has im turned off. On win32, I can query im settings with:
Can this setting be changed on the fly? Do we get notified somehow?
re-scheduling, apparently not too important
See also: #634
Since development has been moved to "future" I'll go ahead and clear this from our queue, since there's nothing for us to do. (Totally not making it look like we are actually being busy)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/572