--- Comment #82 from Mike FABIAN <mfabian(a)redhat.com> ---
(In reply to Stas Sergeev from comment #79)
(In reply to Mike FABIAN from comment #78)
> If you use a keyboard layout, yes. This is an input engine,
> (ab)used to emulate a keyboard layout.
> But that is a very special case for rusle, almost all
> other tables are really input engines, not keyboard layouts.
> And for them, switching into direct mode does not switch to "en" but
> to some unknown keyboard layout which was used before, i.e. the engine
> can be toggled between on ☑ and off ☐. In “off” mode it does
> not have to be US keyboard layout, it can be anything.
What exactly is anything? How to control that?
Let’s say we use the ibus-kkc engine, a Japanese input engine.
It transliterates Latin input to Japanese hiragana, e.g.
ya → や
and then one can convert it to kanji etc.
ibus-kkc does not enforce a keyboard layout, which keyboard
layout is used depends on which was used last.
Now assume we have 3 input sources in the Gnome panel:
de (German keyboard layout)
us (US English keyboard layout)
kkc (Japanese input engine)
Select “us”, then “kkc”, in that case kkc will use
the US keyboard layout, i.e. to type “ya” and get it converted
to や you have to type the key to the right of the left shift key
and then the key to the right of the capslock key.
Now select “de” and then select “kkc” again.
Now “kkc” uses the German keyboard layout!
That means if you press the same 2 keys now which gave you “ya”
on the US layout, you will get “za” instead which kkc transliterates
to ざ. That is good, there is no reason to force a specific layout
for kkc, any layout which can input Latin letters is just fine.
If one switches to direct mode in kkc, the direct mode may behave
like a German keyboard layout or like a US English keyboard layout
depending on what was selected last before switching to kkc.
Engines which do transliteration like kkc (or the Russian translit
table) can usually work with any keyboard layout, so they do not
enforce a special layout when switching to them. In such engines, the
direct mode uses whatever keyboard layout was selected last before
switching to that engine.
However, there are also engines which depend on a specific keyboard
layout. Some Chinese engines which are not transliterating but
have “radicals” (components of Chinese characters) on certain keys
need to enforce a specific keyboard layout. One example is the
Cangjie input method (also supported by ibus-table):
The ibus-table tables “cangjie3” and “cangjie5” therefore automatically
switch to the US keyboard layout when they are selected (That would
not be nice for kkc but is necessary for cangjie).
Another such table is rusle! rusle also needs to have the US keyboard layout.
If rusle were used with a German keyboard layout, the keys for
“н” and “я” would change positions. Because rusle.txt contains:
y н 0
z я 0
and y and z are exchanged when comparing the German and the US keyboard layout.
Therefore, rusle contains:
### The Keyboard Layout used by this table.
### Set to "default" to accept any kind of layout
KEYBOARD_LAYOUT = us
which automatically switches to US keyboard layout when rusle is
selected. Tables which want to keep whatever layout was used
before (typically tables doing some transliteration) have
### This table can be used with any layout capable of typing ASCII.
### Therefore, we should not require a special layout like “us”.
LAYOUT = default
(e.g. translit.txt, the Russian transliteration table has this).
> At least this shows you clearly when the engine is in direct
> (i.e. off) so I think this is much better then still displaying "ru"
> even in direct mode as it was before.
Then how about P (or just whatever) in direct mode,
In direct mode of rusle, it is US layout because rusle enforces US
layout. So the Р (CYRILLIC CAPITAL LETTER ER) doesn’t make much
For tables which do not enforce a layout (like translit or the latex
table in ibus-table) I would not know what layout to display in direct
mode because it depends on what was used last and I cannot figure that
out reliably. So for the latex table I display ☑Σ when it is on
and ☐Σ when it is in direct mode (keyboard layout unknown but the
empty box shows that latex mode is off).
In case of rusle, the keyboard layout in direct mode is actually
known, as explained above, it is US layout.
So I thought that for the tables which enforce some layout, I could
display that in direct mode instead of an empty box followed by the
single character symbolizing the table.
But there are few tables which do that, most of which are Chinese
which already have an exception to display 英 in direct mode. So
displaying “en” would add yet another exception for rusle only. And
how can I get “en” from the xkb keyboard name “us” which is in the
rusle.txt table source? I would need a mapping between the xkb
keyboard layout names and the iso-codes of the languages they support,
which means I would need to parse /usr/share/X11/xkb/rules/base.xml or
use something like libxklavier for that. Seems like overkill.
And displaying “en” in direct mode for rusle would
also have the disadvantage that you cannot see then whether you
are in direct mode of rusle or whether you *really* selected an
US xkb keyboard layout. Which may be a subtle difference because
if it is direct mode of rusle, you switch to Russian with the left shift key,
if it is a US xkb keyboard layout, you switch to Russian by using
the ibus engine switching key (Super+Space by default).
So I think it is better to see the difference.
In most Chinese engines, 中 is displayed in “on” mode and 英 is
displayed in “off” mode (direct input mode). So the 英 for direct
input mode looks visibly different from the “en” if a real English
keyboard layout is selected instead of the direct mode of the Chinese
Similar for Japanese engines like ibus-kkc. ibus-kkc has 6 input modes
and displays the following mode strings in the Gnome panel:
あ Hiragana input mode
ア Katakana input mode
_ｱ Halfwidth katakana input mode
_A English letters and numbers input mode
Ａ Fullwidth English letters and numbers input mode
_A Direct input mode
There is a subtle difference between “English letters and numbers
input mode” and “Direct input mode” although both display the same
mode string “_A”: The “English letters and numbers input mode”
uses preedit and does tab-completion for common English words whereas
the “Direct input mode” just uses the keyboard layout used at the
moment (I think it would be nicer to display something different, but
remember that only 2 characters are allowed by Gnome to display the
mode, so it is not easy to find a 2 character string expressing that
But note that ibus-kkc does not display “en” in direct input mode,
it cannot do that because it could be a different keyboard layout like
German for example (whatever was used before kkc).
but RU in enable mode?
> > IMHO the entire thing can be implemented much better.
> > My current assumption is that this all is needed
> > for some chinese, who may want to add just CN
> > and get all 30 layouts.
> What 30 layouts?
This is how I understand Comment #55:
The second is that most Japanese used to only one IME and would not like to
add two engines.
In MS-Windows 8, Ja IME only for Japanese Windows but 'US' layout and
Chinese IME for Chinese Windows.
I think European people used to switch multiple engines so they haven't
worried about about the input modes.
That's why I thought it may be a good idea to
add multiple engines when you add just one.
> The Chinese engines also switch between on and off, not between
> Chinese and a list of layouts.
Then I am not sure what comment 55 says...
It may be a bit hard to understand when one has not used these Chinese
and Japanese input methods for a while ☹.
> The “☑Р” shows you clearly that you are using your rusle
> and *not* a Russian xkb keyboard layout which would display “ru”
> in the Gnome panel.
I don't understand.
I just open the configurator, click +, then click Russian,
then select Russian Legacy from the list. It says nothing
whether I am adding an xkb layout or ibus engine. How would
In the list of input sources in the “gnome-control-center region”
(That is where you click the + to add more input sources), you
see something like:
English (English - GB (Hunspell)) ⚙
Other (latn-post (m17n)) ⚙
The entries marked with gear-wheels are input-engines,
those without the gear-wheels (like “English (US)” and
“Mike’s layout”) are xkb keyboard layouts.
And how would I add the Russian Legacy xkb layout
and get rid of all the ibus pain? :)
Actually I was wondering about that for quite some time
already: “Why does Stas want to use ibus? Why doesn’t he just
use xkb? xkb would be better for him ...” ☺.
rusle does not use any of the “advanced” features of ibus-table:
- no transliteration
- no completion of longer strings
- no learning from the user input, no statistics which strings are used
- no selection from several possible candidates when typing something
- no user defined transliterations
rusle only “simulates” an xkb layout using ibus-table.
So why not use xkb in the first place?
(I didn’t tell you immediately because your bug reports were *very* good
and useful and helped to fix some real problems in ibus-table).
I’ll try to explain you how to add a Russian legacy xkb layout now …
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug