On 07. sep. 2012 09:41, Daiki Ueno wrote:
Tore Ferner tor...@pvv.org writes:
In wheezy:
Turning off Use system keyboard layout gives me an American
keyboard -
except that all default Norwegian AltGr-characters still works, both
shifted and unshifted. Seems AltGr just bypasses ibus.
It is more likely ibus rather than ibus-m17n which causes the
difference.
OK.
Which target application are you testing on?
My goal is to make multilingual documents with Emacs/Latex/Xetex with
source in utf-8, but for now I am testing in Gedit.
Perhaps the key snooper change might affect the behavior:
https://github.com/ibus/ibus/commit/9ae13a3d
Case 4-c applies to me then?:
$ set | grep -i ibus
CLUTTER_IM_MODULE=ibus
GTK_IM_MODULE=ibus
QT4_IM_MODULE=ibus
XMODIFIERS=@im=ibus
$ IBUS_SNOOPER_APPS=gedit gedit
No difference.
$ IBUS_DISABLE_SNOOPER=1 gedit
No difference.
This also suggests that AltGr should work, at least upstream, see bug
BZ#652201:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/ibus-m17n.html
I'm the one who worked on the bug. As far as I remember, RHEL6
ibus-m17n simply assumes that AltGr is mapped to Mod5. So, the
assumption might not be true on Norwegian keyboard.
If xkb is what defines my AltGr in an ibus relevant way:
My default layout is in /usr/share/X11/xkb/symbols/no:
partial default alphanumeric_keys
xkb_symbols basic {
[snip]
include nbsp(level3n)
include keypad(ossmath)
include kpdl(comma)
include level3(ralt_switch)
};
and /usr/share/X11/xkb/symbols/level3 contains:
default partial modifier_keys
xkb_symbols ralt_switch {
key RALT {
type[Group1]=ONE_LEVEL,
symbols[Group1] = [ ISO_Level3_Shift ]
};
modifier_map Mod5 { ISO_Level3_Shift };
};
---
xev gives for AltGr:
KeyPress event, serial 37, synthetic NO, window 0x521,
root 0xae, subw 0x0, time 182617031, (920,172), root:(922,295),
state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift),
same_screen YES,
XKeysymToKeycode returns keycode: 92
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
---
se, dk, fi de, fr, es, it... also use level3(ralt_switch).
Unfortunately there is no reliable mechanism to map such a virtual
modifier to physical modifer in IBus and the upstream does not want IME
to depend on X11.
I'll consider again if this would be really useful.
1)
From a phonetic viewpoint using more modifiers makes sense, I think. In
Hindi fx, many sounds vary orthogonally along at least 2 dimensions in
a systematic fashion, dimensions that are hardly represented in the
latin alphabet at all.
You have for example 4 d sounds.
Make Shift mean aspirated and unshifted mean unaspirated.
AltGr could mean further back in the mouth, typically retroflex or
glottal.
Then the d key could represent Hindi's 4 d sounds:
द = d
ध = Shift d (aspirated d)
ड = AltGr d (retroflex d)
ढ = Shift AltGr d (aspirated retroflex d)
Similarly for t, k, n, l.
Analogously for i, u, æ (or e), å, for other reasons though.
Other languages may have other orthogonal dimensions that could be
useful to combine in a similar fashion.
And then there are some Hindi sounds that more or less correspond to
Norwegian ones (å/Å, æ/Æ) that would be nice to map. (That's not
directly AltGr relevant, but I haven't figured out how to map Æ, Ø and Å
yet. If Shift cannot be used, why not use AltGr instead?)
But that was perhaps not what you meant by useful...?
Can such orthogonal combination be done just as easily with
pre-/post-composition?
Or maybe I should use a different input mechanism?
2)
Anyway, if AltGr cannot be used and you cannot remap
Shift-non-ascii-letter, things get rather cramped.
And although things would work, the user experience for a non-technical
user is bad: I must either change the mim file for the symbols in the
American layout that I access with AltGr in my layout (i.e. change to
use some other symbols/letters), or I must use the American layout and
many symbols will be located elsewhere than the signs on my keyboard show.
Best regards
Tore
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
