#425 closed defect (needinfo)
Can't use Alt+<SYM> shortcuts in application running inside xpra
Reported by: | Alexei Volkov | Owned by: | Alexei Volkov |
---|---|---|---|
Priority: | major | Milestone: | 2.0 |
Component: | client | Version: | |
Keywords: | keycodes | Cc: |
Description
Actually i found alot of tickets with similar symptoms, but did not find any solution or workaround.
Currently i experience a problen using IDE shortcuts with Alt modifier. All of them appeared on xpra side as Alt + Meta + SYM instead of Alt + SYM. And that's cause an issue to use any Alt based shortcuts.
Attachments (2)
Change History (13)
comment:1 Changed 9 years ago by
Owner: | changed from Antoine Martin to Alexei Volkov |
---|
comment:2 Changed 9 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
Not heard back - closing.
Changed 9 years ago by
Attachment: | xpra_10-4_alt-test.PNG added |
---|
alt test with keyboard Test inside xpra session (0.10.4)
Changed 9 years ago by
Attachment: | windows_local_alt-test(xpra-0-11-keyboardTestTool).PNG added |
---|
alt test with keyboard Test windows local (via xpra 0.11 test tool)
comment:3 Changed 9 years ago by
With windows machine alt+(numbers) allows typing of non-English characters, such as alt+(0241) = ñ.
Inside xpra session, the shortcut doesn't work (and I'm not aware of any other tricks to use non-English characters, aside from typing them locally and copy/pasting them into an xpra session).
Haven't tested to see if OSX option+(character) shortcuts work, but I imagine they don't.
Attached screen shots from keyboard Test tool, inside xpra session vs. windows local. Let me know if you need more extensive samples, which I can type or somehow copy as needed.
comment:4 Changed 9 years ago by
Milestone: | → 1.0 |
---|---|
Resolution: | needinfo |
Status: | closed → reopened |
Re-opening. Thanks for the details.
Not sure what the OP's client OS was since he never followed up. Sounds like win32.
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. (ie: windows Alt+num)
comment:5 Changed 8 years ago by
Resolution: | → needinfo |
---|---|
Status: | reopened → closed |
I am closing this ticket because the OP never followed up.
The windows input method is now in a new ticket: #572
comment:6 Changed 8 years ago by
Note: 0.14 includes new features related to keyboard input and layout selection:
- the ability to switch layouts from the tray
- the
input-method
switch
comment:8 Changed 6 years ago by
Maybe this is a duplicate of #1119, which was backported to v0.16.x - without feedback from the OP, we will never know.
comment:11 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/425
Keyboard is meant to get an overhaul in the next release, hopefully we can address this bug too.
Please add more info as per wiki/Keyboard