Skip to content
This repository has been archived by the owner on Jul 5, 2022. It is now read-only.

support for compose key #43

Open
oetiker opened this issue Jun 13, 2011 · 8 comments
Open

support for compose key #43

oetiker opened this issue Jun 13, 2011 · 8 comments
Milestone

Comments

@oetiker
Copy link

oetiker commented Jun 13, 2011

In rdesktop it was possible to use the compose key to write international characters ... this features was enabled using to enable_compose command in the keymap ... it would be great if similar functionality was available in freerdp as this provides consistent user experiance between working locally and within the rdp session.

@kiilerix
Copy link
Member

oetiker wrote, On 06/13/2011 09:16 AM:

In rdesktop it was possible to use the compose key to write international characters ... this features was enabled using to enable_compose command in the keymap ... it would be great if similar functionality was available in freerdp as this provides consistent user experiance between working locally and within the rdp session.

What is the "compose" functionality are you referring to? "Dead keys"
where you for example first press "umlaut" and then "u" and get a "ü"?
Or that you can hold down "Alt" and enter a character number?

What FreeRDP version have you tested? Have you tried the git master
configured with --with-xkbfile?

/Mads

@oetiker
Copy link
Author

oetiker commented Jun 13, 2011

Mads,

I have not tried HEAD ... willl do ... the compose key (in unix) works like this: if you want ä you type [compose],["],[a]
if you want ß you type [compose],[s],[s] ... so it is sort of like dead key on demand ... on the sun keyboards there was/is a compose key ... on others, people often use the right ctrl key as a replacement.

cheers
tobi

@oetiker
Copy link
Author

oetiker commented Jun 13, 2011

I have now tried the HEAD version with xkbfile and all I get from pressing [compose],["],[a] is

xf_kb_send_key: unknown key down keycode=117 (X keysym=0xFF20)
xf_kb_send_key: unknown key up keycode=117 (X keysym=0xFF20)

and in windows a "a

the compose key is also known as MULTI_KEY

cheers
tobi

@kiilerix
Copy link
Member

oetiker wrote, On 06/13/2011 02:29 PM:

I have not tried HEAD ... willl do ... the compose key (in unix) works like this: if you want ä you type [compose],["],[a]
if you want ß you type [compose],[s],[s] ... so it is sort of like dead key on demand ... on the sun keyboards there was/is a compose key ... on others, people often use the right ctrl key as a replacement.

So the version you tried was 0.8.2? If that is the case then the master
branch will not be any better.

Do that really work in rdesktop if you use a keyboard layout where there
is no other way to enter that key?

The challenge is that the RDP "normally" uses something resembling raw
scancodes and all decoding of keys and keyboard layout handling is done
on the server side by windows. The challenge for keyboard handling in a
RDP client is to tell windows which layout it should use and to get the
right kind of raw scancodes. That leaves little room for client side
compose key handling, and it will only be possible if it can be mapped
to some scancodes in the current layout.

RDP do however also have an option for sending keystrokes as unicode.
That will obviously (AFAIK) not work for sending modifiers and dead keys
to the remote side, but it could perhaps be used for compose key
handling. FreeRDP should thus filter the compose key and not send it to
the server but wait for something that X could decode to a unicode
character.

/Mads

@oetiker
Copy link
Author

oetiker commented Jun 13, 2011

I used c20d01c from git.

It only works in rdesktop if the keymap contains enable_compose. On the windows side, a keyboard has to be selected which supports the keys that can be generated with the compose key ... so if the windows keyboard is US, compose will not work, as there is no key on the windows us keybard for ä ... but if I select a german keyboard on the windows side and enable_compose on rdesktop, it seems that the compose sequence gets translated to the appropriate key-press for windows ...

the approach with sending unicode keys sounds like a really cool way, as this would then just duplicate whatever happens on the unix side ... then no fancy 'pick the right keyboard on the windows side' tricks were necessary.

@kiilerix
Copy link
Member

oetiker wrote, On 06/13/2011 03:48 PM:

It only works in rdesktop if the keymap contains enable_compose. On the windows side, a keyboard has to be selected which supports the keys that can be generated with the compose key ... so if the windows keyboard is US, compose will not work, as there is no key on the windows us keybard for ä ... but if I select a german keyboard on the windows side and enable_compose on rdesktop, it seems that the compose sequence gets translated to the appropriate key-press for windows ...

the approach with sending unicode keys sounds like a really cool way, as this would then just duplicate whatever happens on the unix side ... then no fancy 'pick the right keyboard on the windows side' tricks were necessary.

Ok, so now we know what rdesktop provides, but we want something more
stable than that and we have an idea how to achieve that. On the X side
we should however do like rdesktop: create an input context with
XCreateIC, make sure we ignore the keystrokes it uses for composing, and
get the character with XmbLookupString. I guess that will require that
we completely ignore the server side keyboard layout. That might cause
problems for some applications and will make the server side keyboard
indicators only purpose be to confuse users.

/Mads

@oetiker
Copy link
Author

oetiker commented Jun 13, 2011

how about enabling this only when the compose key is pressed ? it seems that compose has no counterpart on windows anyway ...

@oetiker oetiker closed this as completed Jun 13, 2011
@otavio otavio reopened this Jun 13, 2011
@otavio
Copy link
Contributor

otavio commented Jun 13, 2011

It seems it has been closed by mistake thus I reopened it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants