Xpra: Ticket #572: provide input methods for ms windows clients (alt + numbers)

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..



Tue, 19 Aug 2014 04:36:20 GMT - Antoine Martin: attachment set

the gtk input method selection context dialog


Tue, 19 Aug 2014 04:42:54 GMT - Antoine Martin: owner, milestone changed

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 xim, scim, 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:

the gtk input method selection context dialog

It should be tested without xpra first, as keyboard state issues may hinder testing (and we can fix that separately).


Wed, 20 Aug 2014 21:06:51 GMT - alas:

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.

Little help?


Wed, 20 Aug 2014 21:09:24 GMT - alas: attachment set

ticket 572 test_form_input_py run fail


Thu, 21 Aug 2014 01:15:11 GMT - Antoine Martin:

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).


Fri, 05 Sep 2014 21:19:44 GMT - J. Max Mena:

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 Xorg. link: https://help.ubuntu.com/community/ComposeKey

or if you like Wikipedia

http://en.wikipedia.org/wiki/Compose_key


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.

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!)


Sat, 06 Sep 2014 05:25:11 GMT - Antoine Martin:

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.


Mon, 29 Sep 2014 04:31:36 GMT - Antoine Martin:

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:

SM_IMMENABLED=82
win32api.GetSystemMetrics(SM_IMMENABLED)

Can this setting be changed on the fly? Do we get notified somehow?


Tue, 14 Apr 2015 16:39:03 GMT - Antoine Martin: milestone changed

re-scheduling, apparently not too important

See also: #634


Thu, 03 Dec 2015 21:18:17 GMT - J. Max Mena: owner changed

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)


Sat, 23 Jan 2021 04:59:44 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/572