xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 8 years ago

Last modified 17 months ago

#572 new enhancement

provide input methods for ms windows clients (alt + numbers)

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: future
Component: server Version:
Keywords: Cc:


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

Attachments (2)

input-method-selection.png (25.7 KB) - added by Antoine Martin 8 years ago.
the gtk input method selection context dialog
ticket572-test_form_input_py-run-failure.PNG (307.7 KB) - added by alas 8 years ago.
ticket 572 test_form_input_py run fail

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by Antoine Martin

Attachment: input-method-selection.png added

the gtk input method selection context dialog

comment:1 Changed 8 years ago by Antoine Martin

Milestone: future0.15
Owner: changed from Antoine Martin to alas

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

Last edited 8 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 8 years ago by 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?

Last edited 8 years ago by Antoine Martin (previous) (diff)

Changed 8 years ago by alas

ticket 572 test_form_input_py run fail

comment:3 Changed 8 years ago by 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).

comment:4 Changed 8 years ago by 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


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.

  • Or if we want we can have a "special character" feature where upon holding alt or 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!)

comment:5 Changed 8 years ago by 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.

comment:6 Changed 8 years ago by 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:


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

comment:7 Changed 7 years ago by Antoine Martin

Milestone: 0.15future

re-scheduling, apparently not too important

See also: #634

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 7 years ago by J. Max Mena

Owner: changed from alas to Antoine Martin

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)

comment:9 Changed 17 months ago by migration script

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

Note: See TracTickets for help on using tickets.