Bug 1133127

Hi Mike, I will appreciate if you, as a
first step, will just disable that hotkey
so that it not to break the casual typing.

Hi Mike, I claim that Shift press/release is
not the only cause of this. Yes, when I press/release
Shift, this happens.
But the problem is that it happens on other occasions too.
For example, if the Shift was pressed in the beginning of
line, in the _middle_ of the line I can suddenly get switched
to English. By seeing the typing, I can claim that the letter
_was typed_ while Shift was pressed. The evidence is a capital
letter in the beginning of the line. Also there would be a few
cyrillic non-capital letters between that capital and the
occasional switch, and I can hardly believe I can occasionally
hit Shift while typing non-capitals.
Yet, it _has_ something to do with Shift definitely, and pressing
Shift again, returns me to cyrillic typing.
I think it is some subtle bug that makes Shift that was
pressed earlier, with letters typed, somehow provoke the
switch later.

Is there any logging in ibus that I can enable to let you
see what's going on?

> Is there any logging in ibus that I can enable to let you
> see what's going on?

The startscript /usr/libexec/ibus-engine-table contains:

# Set this variable to something > 0 to get more debug output.
# (Debug output may show up in the log file and/or in the lookup table):
#export IBUS_TABLE_DEBUG_LEVEL=1
#
# Set this to something if you want benchmarking (The profiling output
# will appear in the debug long when "ibus restart" is executed):
#export IBUS_TABLE_PROFILE=yes

When setting the IBUS_TABLE_DEBUG_LEVEL  variable like this:


# Set this variable to something > 0 to get more debug output.
# (Debug output may show up in the log file and/or in the lookup table):
export IBUS_TABLE_DEBUG_LEVEL=1
#
# Set this to something if you want benchmarking (The profiling output
# will appear in the debug long when "ibus restart" is executed):
export IBUS_TABLE_PROFILE=yes

and restarting ibus ("ibus restart"), some more debug output
will be written to ~/.ibus/tables/debug.log

You can try "tail -F ~/.ibus/tables/debug.log"

while typing and see whether anything interesting appears.

(In reply to Stas Sergeev from comment #2)
> Hi Mike, I claim that Shift press/release is
> not the only cause of this. Yes, when I press/release
> Shift, this happens.
> But the problem is that it happens on other occasions too.
> For example, if the Shift was pressed in the beginning of
> line, in the _middle_ of the line I can suddenly get switched
> to English. By seeing the typing, I can claim that the letter
> _was typed_ while Shift was pressed. The evidence is a capital
> letter in the beginning of the line. Also there would be a few
> cyrillic non-capital letters between that capital and the
> occasional switch, and I can hardly believe I can occasionally
> hit Shift while typing non-capitals.
> Yet, it _has_ something to do with Shift definitely, and pressing
> Shift again, returns me to cyrillic typing.
> I think it is some subtle bug that makes Shift that was
> pressed earlier, with letters typed, somehow provoke the
> switch later.

Is that a timing issue or is there an exact key sequence which
can be used to reproduce this problem, no matter how slowly it is typed?

Or is it only happening when typing fast?

So far I've seen that with both slow and
fast typing. Have not identified the particular
key sequence, but Shift is always involved.
But the problem is, I can't say that I've seen
that yesterday. Just today. This makes me worry
that it depends on a "moon phase", so tomorrow,
when I'll try your suggestions about logging, I
may not be able to reproduce that any more...

I've found a strange thing.
In control center I have only next input
source hotkey Ctrl-Menu and modifier-only
switch RightCtrl-Shift. Everything else
is disabled. Still, RShift-LShift combo
also switches the layouts! (including the
indicator change)
It shouldn't, it is not set anywhere.
Any idea?

Well, the bug with occasional layout
switching appear to depend not on a moon
phase, but on whether or not you have
xine player playing in the background...
Without xine I was not able to reproduce
it, but with xine it seems easily reproduceable.
And it doesn't even depend on shift!

1. Start xine with some movie
2. Switch to another window where you can type
3. Switch to RU using rusle
4. Start typing, very very quickly, just type any garbage, don't hit Shift

Eventually the layout will switch to latinic.
It takes me about 20 seconds to reproduce,
although of course for you it may be different...
Surprisingly, the log shows this as its last line:
_table_mode_process_key_event() repr(key)=Shift_L 0x00000000
But no, I was not hitting Shift!

Hmm, in fact, don't even need to type anything.
Just hit any key and hold it forever. It will
autorepeat, and 20 seconds later it will switch
to latinic.

You still need xine playing in the background,
otherwise you can't reproduce in any way.
Yes, that sounds silly, but is true.

Is comment#6 and comment#7 the same problem or are these different problems?

Hi, they are different.
To not pollute this bug, I opened
https://bugzilla.redhat.com/show_bug.cgi?id=1134299
for comment #6.

Thank you!

(In reply to Stas Sergeev from comment #8)
> Hmm, in fact, don't even need to type anything.
> Just hit any key and hold it forever. It will
> autorepeat, and 20 seconds later it will switch
> to latinic.

I cannot reproduce that, neither with xine nor mplayer.

Well, that's expected.
So what we have now is that the log claims
I hit shift. Of course if I just hold a single
key for 20 sec, I can't occasinally hit Shift.
Is there any other logging, ibus level perhaps
(rather than ibus-engine-tables), that can make
it clearer where does the fake Shift come from?
Since I am reproducing it reliably, I could do
some debugging too.

Is it really switching to Latin mode? I.e. if you look in the Gnome panel menu,
do you sometimes see “Direct Input (Left Shift)” there?

I suspect you do not see that.

If I apply a patch like this:

diff --git a/engine/table.py b/engine/table.py
index 10cf763..0a380d9 100644
--- a/engine/table.py
+++ b/engine/table.py
@@ -1841,6 +1841,7 @@ class tabengine (IBus.Engine):
         Key Events include Key Press and Key Release,
         modifier means Key Pressed
         '''
+        time.sleep(1)
         sys.stderr.write("mike do_process_key_event()\n")
         if self._has_input_purpose and self._input_purpose in [IBus.InputPurpose.PASSWORD, IBus.InputPurpose.PIN]:
             return False
lines 1-12/12 (END)

I.e. add a sleep in the key event processing function:

    def do_process_key_event(self, keyval, keycode, state):
        '''Process Key Events
        Key Events include Key Press and Key Release,
        modifier means Key Pressed
        '''
        time.sleep(1)

Then I get a similar behaviour as you are reporting.

When pressing the “a” key and keeping it pressed, I get something like:

    фффффaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaффффф

The idea of the sleep(1) is to make the key event processing
artificially slow, just as if there is a very high system load.  I was
guessing that maybe your system is much slower than mine and xine is
enough to load your system so much that the key event processing in
ibus-table cannot keep up with your speed of typing any more.

If that happens, one gets the

    фффффaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaффффф

When holding the ”a” key.

*But*, I *cannot* find

    _table_mode_process_key_event() repr(key)=Shift_L 0x00000000

in the log, so I am not sure whether this is the same effect or not.

The “a” characters in

    фффффaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaфaaaaaaaaaaaaaaффффф

do not even reach the event processing function in ibus-table in that
case (I can check that with the help of the log, only the “a”
characters which have been correctly converted to “ф” have been
handled in ibus-table’s key event processing function, the
unconverted “a” characters “bypassed” ibus-table’s key event
processing function). Some input buffer outside of ibus-table
(in ibus or gtk?) seems to overflow. When that buffer overflows, the
additional “a” characters typed go directly into the application
and are not handled by ibus-table anymore.

*But*, not only I cannot see the

    _table_mode_process_key_event() repr(key)=Shift_L 0x00000000

in the log in that case nor can I see the mode changing from “Р
(Left Shift)” to “Direct input (Left Shift)” in the properties menu
you get from the gnome-panel.

So I am not sure whether I am on the right track here.

(In reply to Mike FABIAN from comment #15)
> Is it really switching to Latin mode? I.e. if you look in the Gnome panel
> menu,
> do you sometimes see “Direct Input (Left Shift)” there?
> 
> I suspect you do not see that.
What exactly do you mean?
If you mean a layout indicator, then it would still
display RU. I am not sure where can I see "Direct Input".
But the switch is _identical_ to what happens when LShift
is pressed, because in fact even log says the LShift is
pressed.

(In reply to Mike FABIAN from comment #16)
> So I am not sure whether I am on the right track here.
No, this looks different.
For me the switch is permanent (as is by LShift), but
for you - only the overflow char goes directly.
I think the overflow case should be handled somehow
differently than to pass the char directly, but I am
not sure what is the right way of handling an overflow
case. In my case somehow xine makes fake LShifts to
appear... This is not an overflow case.

Note that I tried to replace xine by the
tight loops and other CPU blowers - all in
vain. xine is magic here, it is not because
of the CPU load.

(In reply to Stas Sergeev from comment #17)
> (In reply to Mike FABIAN from comment #15)
> > Is it really switching to Latin mode? I.e. if you look in the Gnome panel
> > menu,
> > do you sometimes see “Direct Input (Left Shift)” there?
> > 
> > I suspect you do not see that.
> What exactly do you mean?
> If you mean a layout indicator, then it would still
> display RU.

No, not the layout indicator which is directly visible in
the gnome panel.

But if you click on that layout indicator, a menu opens.

On top of that menu are the input methods and keyboard layouts
you have configured.

If you have “rusle” selected and the layout indicator
displays “ru” and you click it to open the menu,
you find the following near the bottom of the menu (5th menu
line counting from the bottom:

    Р (Left Shift)

or

    Direct input (Left Shift)

Typing the left Shift key toggles between these two modes.

In case of overflow, there shift key has been processed
by ibus-table’s key event function, therefore this
input mode does not toggle.

But you seem to see a real left shift key because it is in the
log. And because you say the change is permanent for you.  Therefore,
in your case the above menu entry should be toggled to “Direct input
(Left Shift)”.



> I am not sure where can I see "Direct Input".
> But the switch is _identical_ to what happens when LShift
> is pressed, because in fact even log says the LShift is
> pressed.

(In reply to Stas Sergeev from comment #19)
> Note that I tried to replace xine by the
> tight loops and other CPU blowers - all in
> vain. xine is magic here, it is not because
> of the CPU load.

So it is not because of the CPU load and real left shift keys
are somehow passed to ibus-table. 

It is very puzzling how xine can do that. I have no idea at the moment.

Why doesn’t xine do that on my system?

I call xine like this from the command line:


    xine somevideo.mp4
“xine (X11 gui) - 無償の動画プレイヤー v0.99.8.“ starts in that case.

Or should I use some other way of starting xine?
Maybe gxine?

In what kind of program do you do the typing with rusle while xine runs?
(I typed into gnome-terminal).

(In reply to Mike FABIAN from comment #21)
> Why doesn’t xine do that on my system?
There are a few ways to get an answer to this:
1. You can suggest me how to enable more logging
and/or I'll do some debugging on my own.
2. I give you an ssh. Hopefully with "ssh -X"
the thing is reproduceable.

> I call xine like this from the command line:
>     xine somevideo.mp4
> “xine (X11 gui) - 無償の動画プレイヤー v0.99.8.“ starts in that case.
That's what I do too.

> Or should I use some other way of starting xine?
> Maybe gxine?
Haven't tried gxine yet, will do at the evening.

> In what kind of program do you do the typing with rusle while xine runs?
> (I typed into gnome-terminal).
In firefox, like in this exactly bug form.
Also in pidgin.
Haven't yet tried the gnome-terminal, but I am
pretty sure its the same.

When xine is running, the autorepeat typing is
noticeably lagging, there are a "huccups". But
this is not because of the CPU load, it just
somehow affects only ibus. :)

(In reply to Stas Sergeev from comment #22)
> (In reply to Mike FABIAN from comment #21)
> > Why doesn’t xine do that on my system?
> There are a few ways to get an answer to this:
> 1. You can suggest me how to enable more logging
> and/or I'll do some debugging on my own.

I have some more debug prints which I did not
permanently put into the source yet:

https://github.com/mike-fabian/ibus-table/commits/miketmp
https://github.com/mike-fabian/ibus-table/commit/9f4218ca58bbca1eb020579ee98d687e944f4df8

This patch should apply to your version of ibus-table.

> 2. I give you an ssh. Hopefully with "ssh -X"
> the thing is reproduceable.

I don’t see your gnome-panel then and will probably not be able to switch
input methods.

This gave me a weird idea though.

I tried this:

    1) Run xine somevideo.mp4 in gnome-terminal number 1.
    2) Open another gnome-terminal, number 2, in that terminal
       run: “ssh -X localhost”
    3) Switch input method to rusle, focus terminal number 2,
       press a key there and hold it. After a while it switches from
       “ф” to “a” *permanently*. The property menu (in the menu
       which opens when clicking on the input mode indicator
       in the gnome-panel) has switched to "Direct Input (Left Shift).
       I the debug.log I find:
       _table_mode_process_key_event() repr(key)=Shift_L 0x00000000

This does *not* occur without step 1), i.e. without running xine!

(I also tried mplayer but the problem did not occur when using mplayer
instead of xine).

Looks like I can reproduce your problem now when I do the input
in a terminal after doing “ssh -X localhost” in that terminal.

> When xine is running, the autorepeat typing is
> noticeably lagging, there are a "huccups". But
> this is not because of the CPU load, it just
> somehow affects only ibus. :)

I don’t see that, it still appears fast to me in the
terminal after “ssh -X localhost”.

I can *easily* reproduce it as well by typing in firefox when xine
is running! Far easier than in the “ssh -X localhost” shell.
I also see the lag  in the autorepeat and the “hiccups”.

I cannot reproduce it by typing in a “normal” terminal
(not running “ssh -X localhost”).

Also reproducible using gedit while xine is running.

(In reply to Mike FABIAN from comment #23)
> Looks like I can reproduce your problem now when I do the input
> in a terminal after doing “ssh -X localhost” in that terminal.
Hurray!!! :)
You may not believe this, but when I first tried ibus
about 2 years ago (when it just appeared in fedora), it
was randomly typing chars for me, without any keypresses!
It was completely impossible to use it, so I disabled
it in im-chooser.
Now the problem reduced to just LShift, and the fact
that you reproduced it, is a sign that it will soon
vanish. :)

> I don’t see that, it still appears fast to me in the
> terminal after “ssh -X localhost”.
Yes, it is fast, but with occasional hiccups for me.
The layout switch also happens during a small hiccup
delay.

Another interesting test:

    1) Run xine somevideo.mp4 in gnome-terminal number 1.
    2) Open another gnome-terminal, number 2, in that terminal
       run: “ssh -X localhost”
    3) ibus exit
       (no ibus is running now, if you want to start it again
       later you can use “ibus-daemon -drx”).
    4) start “xev” in the terminal from 2)
    5) put mouse over the “xev” window and let it sit there.
    6) just wait and watch the output of xev in the  terminal

From time to time, Shift_L and Control_L events are coming!

(In reply to Mike FABIAN from comment #27)
> Another interesting test:
> 
>     1) Run xine somevideo.mp4 in gnome-terminal number 1.
>     2) Open another gnome-terminal, number 2, in that terminal
>        run: “ssh -X localhost”

That “ssh  -X localhost” is not even necessary, I even
see Shift_L and Control_L events in xev without that.

>     3) ibus exit
>        (no ibus is running now, if you want to start it again
>        later you can use “ibus-daemon -drx”).
>     4) start “xev” in the terminal from 2)
>     5) put mouse over the “xev” window and let it sit there.
>     6) just wait and watch the output of xev in the  terminal
> 
> From time to time, Shift_L and Control_L events are coming!

Do you mean, its an Xorg bug, not even ibus?

(In reply to Stas Sergeev from comment #29)
> Do you mean, its an Xorg bug, not even ibus?

maybe a xine bug?

After “ibus exit”, there are no ibus related processes running anymore.

It looks like xine is “generating” Shift_L and Control_L key events
from time to time. Very strange.

I opened this bug against xine:

https://bugzilla.redhat.com/show_bug.cgi?id=1134406

Hi Mike, I am hitting something really weird
now. Not sure when/why that started to happen.

In rusle mode now when I type, the last char
is always underlined. This is not a problem by
itself. The problem is that now if I hit a left
arrow button, this char gets selected, but I
can't move the cursor! Other arrow buttons do
not work too. And if, instead of arrow, I switch
back to EN, the last char, that was underlined,
gets erased! But at least then arrow keys start
to work again (until I switch back to rusle).

I guess I am hitting some super-duper cool ibus
feature that I occasionally enabled by a super-secret
key combo... just as it always happen. :)

I cannot reproduce this at the moment.
If you have any more details on how to reproduce it, this would ge great.

What are your settings for rusle? Mine are:

$ dconf dump /desktop/ibus/engine/table/rusle/
[/]
onechar=false
inputmode=1
lookuptablepagesize=9
lookuptableorientation=true
autowildcard=true
multiwildcardchar=''
singlewildcardchar=''
alwaysshowlookup=false
autoselect=true
endeffullwidthpunct=false
tabdeffullwidthpunct=false
spacekeybehavior=false
chinesemode=0
tabdeffullwidthletter=false
autocommit=true
endeffullwidthletter=false

I guess you accidentally did hit Ctrl+/ which switches
between "Direct commit mode" and "Normal commit mode.

I.e. your settings are:

$ dconf dump /desktop/ibus/engine/table/rusle/
[/]
onechar=false
inputmode=1
lookuptablepagesize=9
lookuptableorientation=true
autowildcard=true
multiwildcardchar=''
singlewildcardchar=''
alwaysshowlookup=false
autoselect=true
endeffullwidthpunct=false
tabdeffullwidthpunct=false
spacekeybehavior=false
chinesemode=0
tabdeffullwidthletter=false
autocommit=false
endeffullwidthletter=false


"autocommit=false" is the culprit.

This option does not make any sense for rusle either.  For some
Chinese input methods it is important.

I am not yet sure whether I can disable that option for all non-CJK
input methods. Thinking  about it...

For most input methods, typing one character does not give a unique
result, like it does with rusle where each single character maps to
one other character and that’s it.

Even the Russian translit input method is not like that, for example
when typing C, it cannot yet commit the character to the application
because translit.txt contains:

C	Ц	1000
Ch	Ч	1000
CH	Ч	1000

Therefore, it has to wait whether a “h” or a “H” or something else
follows.  When typing a “C” with translit, Ц is shown underlined.
The underline shows you that it is in “preedit”, it has not yet been
passed to the application. Waiting for more input. Until a resulting
character is matched exactly by typing more input or by selecting a
character from the candidate list (if the option to show the candidate
list is on), you see something in preedit underlined.  Then, when the
input is unique or a candidate selected, the preedit is committed. In
case of translit, if you type "Cx”, the Ц is committed because it is
now known that Ch -> Ч is not possible anymore.

There are two ways to commit: Direct commit to the application or
commit to preedit. Committing to preedit makes it possible to type more
characters, commit them to preedit as well and create a possibly very
long preedit. Finally one can commit that long preedit manually by
typing space.

For some Chinese input methods, such as Wubi, this feature is used to
define new shortcuts. One types several Chinese characters, commits
them all to preedit, finally commits that preedit with space and then
a new shortcut for the whole Chinese string consisting of many Chinese
characters is automatically defined according to some rules.

That is completely useless for rusle.  rusle is a fixed conversion
table, no new shortcuts are ever defined.  Therefore, for rusle, that
“Normal commit mode” which commits to preedit is useless.

I must think whether I can automatically determine which tables need
this “Normal commit” option and which don’t to be able to disable it
automatically for tables where it makes no sense.

By the way, if you open the setup tool for rusle,
at the bottom there is a button 

[Restore all defaults]

This button takes you to sane defaults for the current
table, i.e. defaults which are known to work well for that table.
In case of rusle, it also resets from "Normal commit" to "Direct commit".

There is another option which is not yet disabled for rusle
but does not make any sense for rusle. It is the
option which toggles  between "Phrase mode" and "Single char mode"
(short cut Ctrl-;). Fortunately, for rusle this option
makes no differenc whatsoever because rusle only has single characters
as results.

This option is for input methods where some input key sequence result
in huge numbers of candidate matches. For example some Chinese input methods
give long lists of matches for the same input sequence and some of these
matches are not single characters but longer strings. If one wants to
type a specific single Chinese character, this character might be difficult
to find in the candidate list because other matches which are longer strings
are higher up in the candidate list because their statistical probability is
higher. So when one wants to input a certain single character, it might be
easier to temporarily switch to "Single character mode".

But of course this makes no sense for rusle.

I am also thinking about disabling that option for input methods where it
makes  no sense. At least it doesn't hurt rusle,  but there is
a superfluous entry in menu which opens when you click in the 
input method indicator in the Gnome panel.

(In reply to Mike FABIAN from comment #36)
> In case of rusle, it also resets from "Normal commit" to "Direct commit".
Hello Mike, so when I see in the menu
"Direct commit mode", does it mean this is a current
mode, or it is a "click here to enter that mode" option?
Very ambiguous, how about a normal practice of a check boxes...

So: then I see in the menu "Direct commit mode", the bug
does not happen. When I see in the menu "Normal commit mode",
everything is screwed up.

I also wonder why the user is supposed to
know what is "Normal commit" and "Direct commit".
IMHO a completely meaningless things, are they
really needed in the main language menu?

(In reply to Stas Sergeev from comment #38)
> (In reply to Mike FABIAN from comment #36)
> > In case of rusle, it also resets from "Normal commit" to "Direct commit".
> Hello Mike, so when I see in the menu
> "Direct commit mode", does it mean this is a current
> mode,

Yes, that is the current mode.

> or it is a "click here to enter that mode" option?
> Very ambiguous, how about a normal practice of a check boxes...

Yes, it is a bit weird. One does not know to which mode it will
change when clicking.

In Chinese input methods, there is one menu entry which toggles between
5 states each time one clicks the menu entry:

0) Only simplified Chinese
1) Only traditional Chinese
2) Simplified Chinese preferred
3) Traditional Chinese preferred
4) All Chinese characters shown, no special preference

So after clicking the menu 5 times one is back to where one came from.

This is confusing and ugly.

I have on my todo list to replace these toggles in the menu
by sub-menus with check boxes. Probably that is what you suggest as well.
If you want to see how the sub-menus with check boxes look like,
you can see it in ibus-kkc (A Japanese input method).

There is one problem stopping me from doing that now: If one uses a
non-Gnome desktop, for example XFCE, then ibus can display a "floating
panel" which is always visible, not only when the menu is opened. This
"floating panel" always shows these options in form of colourful
icons. With mouse over, the icons show what it means and what mode one
will switch to when clicking it.

When one wants to change for example from the Chinese mode 0 to
Chinese mode 4 (as above), one can click one of these icons 4 times.
This is much faster than opening the menu 4 times and clicking on
a menu entry 4 times (lots of mouse movement!).

So it is ridiculous doing this via the menu, it is not so bad with the
floating panel. Some people like the floating panel.

> So: then I see in the menu "Direct commit mode", the bug
> does not happen. When I see in the menu "Normal commit mode",
> everything is screwed up.

Yes, "Normal commit mode" makes no sense whatsoever for rusle.
Therefore, "Direct commit mode" is the default for rusle. This option
in rusle.txt does make "Direct commit mode" the default:

### If true then the result string will be committed to client automatically.
### This should be used with AUTO_SELECT = TRUE.
AUTO_COMMIT = TRUE

"Normal commit mode" is useful for some input methods though, mainly
for some Chinese input methods.

I have to think whether there are any non-CJK input methods where
"Normal commit mode" is useful. If not, then I can disable that option
for all non-CJK input methods.  Just like I disabled the
fullwidth/halfwidth options for non-CJK input methods.

(In reply to Stas Sergeev from comment #39)
> I also wonder why the user is supposed to
> know what is "Normal commit" and "Direct commit".
> IMHO a completely meaningless things,

You are right that it is very bad that there is no good documentation
explaining this. I should add documentation for these options.

> are they really needed in the main language menu?

For some Chinese input methods, for example Wubi, it is useful and
should be there.

(In reply to Mike FABIAN from comment #40)
> I have on my todo list to replace these toggles in the menu
> by sub-menus with check boxes. Probably that is what you suggest as well.
> If you want to see how the sub-menus with check boxes look like,
> you can see it in ibus-kkc (A Japanese input method).
I added Japanese SKK, and the sub-menu indeed looks much
better than what we have for rusle now.

> When one wants to change for example from the Chinese mode 0 to
> Chinese mode 4 (as above), one can click one of these icons 4 times.
> This is much faster than opening the menu 4 times and clicking on
> a menu entry 4 times (lots of mouse movement!).
> So it is ridiculous doing this via the menu, it is not so bad with the
> floating panel. Some people like the floating panel.
I find it strange that you compare floating panel
with current rusle menu, and not with the SKK sub-menu
style. From your description I can guess that sub-menu
is still better because it allows any change in just 1
mouse click whereas floating panel require 4.

(In reply to Mike FABIAN from comment #41)
> (In reply to Stas Sergeev from comment #39)
> > I also wonder why the user is supposed to
> > know what is "Normal commit" and "Direct commit".
> > IMHO a completely meaningless things,
> You are right that it is very bad that there is no good documentation
> explaining this. I should add documentation for these options.
Well, documentation is a good thing, but the menu items
itself should be somewhat sensible too. For example,
"Phrase mode" means something, while "Normal commit mode"
means purely nothing, IMHO.
Almost certainly the options that are useful for users,
can have a meaningful name. Options with meaningless
names are usually invented by programmers for programmers. :)

> > are they really needed in the main language menu?
> For some Chinese input methods, for example Wubi, it is useful and
> should be there.
Do they really need to switch it from default all that often?

Moved unrelated discussion:
https://bugzilla.redhat.com/show_bug.cgi?id=1135759

(In reply to Stas Sergeev from comment #42)

> > When one wants to change for example from the Chinese mode 0 to
> > Chinese mode 4 (as above), one can click one of these icons 4 times.
> > This is much faster than opening the menu 4 times and clicking on
> > a menu entry 4 times (lots of mouse movement!).
> > So it is ridiculous doing this via the menu, it is not so bad with the
> > floating panel. Some people like the floating panel.

> I find it strange that you compare floating panel
> with current rusle menu, and not with the SKK sub-menu
> style. From your description I can guess that sub-menu
> is still better because it allows any change in just 1
> mouse click whereas floating panel require 4.

Floating panel requires 4 clicks in case of a toogle
and no submenu. I.e. total 4 actions.

If there were a submenu, it would need one click, a mouse movement to
the submenu and another click (In the floating panel). Total 3 actions.

When one is not using the floating panel, in case of the toogle style,
one needs 1 click to open the menu, one mouse movement and one click
on the toggle to change the toggle once. I.e. to change the toogle 4
times this makes 8 clicks and 4 mouse movements. Togal 12
actions.

Whereas in case of the submenu style one needs 1 click to
open the menu, one mouse movement to the menu entry, one click to open
the submenu, another mouse movement and a click on the submenu
entry. Total 3 clicks and 2 mouse movements. Total 5 actions.

That means when using the menu from the panel, the toggle is
very wasteful, far more clicks and movements.

When using the floating panel, the difference is not that big.

Although the difference is small when using the floating panel,
the submenu style is much easier to understand and therefore better.

So I should really tackle that item from my todo list to convert
these toogles into submenus.

> (In reply to Mike FABIAN from comment #41)
> > (In reply to Stas Sergeev from comment #39)
> > > I also wonder why the user is supposed to
> > > know what is "Normal commit" and "Direct commit".
> > > IMHO a completely meaningless things,
> > You are right that it is very bad that there is no good documentation
> > explaining this. I should add documentation for these options.
> Well, documentation is a good thing, but the menu items
> itself should be somewhat sensible too. For example,
> "Phrase mode" means something, while "Normal commit mode"
> means purely nothing, IMHO.
> Almost certainly the options that are useful for users,
> can have a meaningful name. Options with meaningless
> names are usually invented by programmers for programmers. :)

Yes, I will change the wording of the "Normal commit mode" and
"Direct commit mode" options.

> > > are they really needed in the main language menu?
> > For some Chinese input methods, for example Wubi, it is useful and
> > should be there.
> Do they really need to switch it from default all that often?

Not sure, maybe most Wubi user leave it to "Normal commit mode" and
don’t change it, but I am not sure.

Hi Mike.

This is the last severe bug for which I
still don't have either a fix or work-around.
It gives lots of problems.
Many people these days, who chat in the internet
way too much, type without any capitals or punctuation -
do you want me to join these circles as well by
disallowing the use of Shift? :)

I really still don't understand why that
short-cut is needed. You explain that
---
For Chinese, this is used often as a quick way to toggle between
Chinese and English mode (faster than switching between two input
sources).
---
but I still don't understand how the hardcoded
short-cut can be any better or faster than the
configurable one? There is already a configurable
short-cuts for this, so I am confused.

(In reply to Stas Sergeev from comment #45)
> Hi Mike.
> 
> This is the last severe bug for which I
> still don't have either a fix or work-around.
> It gives lots of problems.
> Many people these days, who chat in the internet
> way too much, type without any capitals or punctuation -
> do you want me to join these circles as well by
> disallowing the use of Shift? :)

No, of course not, I’ll fix it.

Until I fix it, you can use this as a workaround:

diff --git a/engine/table.py b/engine/table.py
index c992a3f..dd8ba74 100644
--- a/engine/table.py
+++ b/engine/table.py
@@ -1859,9 +1897,9 @@ class tabengine (IBus.Engine):
     def _process_key_event (self, key):
         '''Internal method to process key event'''
         # Match mode switch hotkey
-        if self._editor.is_empty() and (self._match_hotkey(key, IBus.KEY_Shift_L, IBus.ModifierType.SHIFT_MASK | IBus.ModifierType.RELEASE_MASK)):
-            self.do_property_activate("status")
-            return True
+#        if self._editor.is_empty() and (self._match_hotkey(key, IBus.KEY_Shift_L, IBus.ModifierType.SHIFT_MASK | IBus.ModifierType.RELEASE_MASK)):
+#            self.do_property_activate("status")
+#            return True
 
         # Match full half letter mode switch hotkey

> I really still don't understand why that
> short-cut is needed. You explain that
> ---
> For Chinese, this is used often as a quick way to toggle between
> Chinese and English mode (faster than switching between two input
> sources).
> ---
> but I still don't understand how the hardcoded
> short-cut can be any better or faster than the
> configurable one?

Of course configurable is better.

> There is already a configurable short-cuts for this, so I am
> confused.

ibus-table does not have configurable shortcuts at the moment.
All shortcuts in ibus-table are hardcoded.

I want to make them configurable, but that is a bit of work.

(In reply to Mike FABIAN from comment #46)
> Until I fix it, you can use this as a workaround:
Thanks, that works!

> ibus-table does not have configurable shortcuts at the moment.
> All shortcuts in ibus-table are hardcoded.
> 
> I want to make them configurable, but that is a bit of work.
But how is that different from short-cuts in
gnome-control-center, that are ibus-wide, not
specific to ibus-tables?

I mean, there are the configurable short-cuts
to select between EN and RU, so why also the
hardcoded one?

(In reply to Stas Sergeev from comment #48)
> I mean, there are the configurable short-cuts
> to select between EN and RU, so why also the
> hardcoded one?

Selecting between US English keyboard  ("en") and ibus-table "rusle" ("ru")
is switching from one ibus-input engine to another.
So that is an ibus shortcut.

Switching within ibus-table between "table mode" and "direct input"
does not switch to a different input engine, it is still ibus-table.
This is completely within ibus-table. Some ibus input engines have their
own keyboard shortcuts for internal things. ibus itself doesn’t know about
these, therefore they do not appear in the gnome-control-center.

You can try the Japanese ibus engines 'anthy' or 'kkc' (= 'Kanji Kana')
for example, the both have quite a lot of keyboard shortcuts.
When you switch to 'anthy' or 'kkc' and then open their setup tool,
you will find a tab where these keyboard shortcuts are listed and
can be changed.

ibus-table has far fewer keyboard shortcuts than 'anthy' and 'kkc' and
unfortunately they are all hardcoded and not changeable in the setup
tool. Nobody ever implemented making the keyboard shortcuts
configurable in ibus-table.

I will do that, but first I am changing the ibus-table menus from
toggles to sub-menus.

I completely understand what you say.
Unfortunately this does not answer the question:
why the ibus-tables-specific shortcut is needed
for something that ibus already has?
The examples you mentioned with other engines,
likely do not have their analogues in gnome-control-center.

I understand that this is "somewhat" different.
One is switching the engine, other is not.
But for the end-user - what's the difference?

(In reply to Stas Sergeev from comment #50)
> I completely understand what you say.
> Unfortunately this does not answer the question:
> why the ibus-tables-specific shortcut is needed
> for something that ibus already has?
> The examples you mentioned with other engines,
> likely do not have their analogues in gnome-control-center.

Ah, OK, you are wondering why a switch between table mode and direct
input is needed when one could just as well switch to a keyboard
layout like the US English layout using ibus?

(In reply to Stas Sergeev from comment #51)
> I understand that this is "somewhat" different.
> One is switching the engine, other is not.
> But for the end-user - what's the difference?

Both anthy and kkc also have this switch to "direct input mode",
almost the same way ibus-table has.

The difference for the end user is that changing with ibus
to some keyboard layout is a switch of an engine and might
take a few  milliseconds (depending on system load).

Switching to direct input mode without leaving the current ibus engine
is faster, almost instantaneous.

To me this makes no difference, I always switch to a keyboard layout
using the ibus hotkey when I want direct keyboard input, I think this
is plenty fast enough, I don’t notice a delay. And, doing it that
way, I only have to remember how to switch engines using ibus (I use
the default hotkey Super+Space). If I used the direct input modes of
the engines, I have to remember the keybinding to do that for each
engine.

How to switch to direct input mode in some ibus engines:

ibus-table:         Shift
anthy:              Control+J
kkc:                Alt+`
intelligent pinyin: Shift

In case of intelligent pinyin, one choose between Shift and Control in
the setup tool (but not disable it). In case of anthy and kkc, one can
define any shortcut one likes (but no modifier only shortcut!) or
disable the shortcut. In case of ibus-table, it is currently not
configurable at all.

For some users, the tiny delay when switching to a keyboard layout
using ibus compared to switching to direct mode within their input
engine seems to be very important though, we had a lot of discussion
about this. Not every ibus input engine has a direct mode though, and
for the engines which have a direct input mode, the default
keybindings to switch to direct input mode are different. Some users
even requested that all ibus engines which do not yet have an direct
input mode should add one and maybe make the default keyboard
shortcuts for switching to direct input mode the same for all engines.
I think it is hard to find a solution everybody can agree on here.

But in any case, as some users really like being able to switch
to direct input mode without leaving the engine, I cannot remove
that feature from ibus-table.

And, as typing Chinese does not use upper case letters, they have no
problem using only Shift as the hotkey to switch to direct input mode.
You see that intelligent pinyin also uses Shift by default.

That looks like Chinese users prefer a modifier only shortcut like
Shift or Control for this because it is one less key to type compared
to for example Alt+` in kkc.

So I will probably keep switching to direct input as a modifier only
shortcut but make it user configurable between [Shift|Control|shortcut
disabled]. And make Shift the default for Chinese tables and
“shortcut disabled” the default for non-Chinese tables.

Another thing I forgot:

ibus-anthy and ibus-kkc have more input modes then just “Japanese”
and “Direct input”. They have several Japanese modes (“Hiragana”,
“Katakana”, “Halfwidth Katakana”) and several Latin modes
(“Halfwidth English letters and numbers”, “Fullwidth English
letters and numbers”, “Direct Input”).

I.e. ibus-anthy and ibus-kkc have special modes to enter fullwidth
Latin text.

(Ｔｈｉｓ ｉｓ ｆｕｌｌｗｉｄｔｈ Ｌａｔｉｎ ｔｅｘｔ １２３).

ibus-table however has only “Table mode” and “Direct input”.  If
the table is Chinese, options for halfwidth and fullwidth are enabled
though (disabled for non-Chinese tables like “rusle”) and they
are usable in “Direct mode” as well.
That means the “Direct mode” of ibus-table is not really completely
direct, it can be abused to type fullwidth Latin by switching
to “Direct mode” *and* switching to fullwidth.

Maybe it would be nicer if ibus-table had a special fullwith Latin
mode and the “Direct mode” were really always direct, just like
ibus-anthy and ibus-kkc. So maybe I’ll make this more like ibus-anthy
and ibus-kkc later.

Could you please point me to the forum
where users demand that feature because
of a small delay (or for any other reason)?
I'd like to double check that because maybe
you just refer to something like this:
https://bugzilla.redhat.com/show_bug.cgi?id=1133283
which is also about a switching delay, but is just
a bug. The most important thing is not the
delay itself, but the fact that during that
delay the chars still appear in previous layout!

Otherwise it looks like a very minor performance
tweak, and I wonder if it fits the current gnome
policy about minimalistic configuration sets.

The engine specific trigger key has two reasons.

The first is that the language has the special shortcut keys. E.g. Zenkaku_Hankaku key for Japanese and Hangul key for Hangul. In MS-Windows 8, Super+space is to switch engines and Zenkaku_Hankaku key switches the direct mode and Japanese.

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.
I'm not sure about Russian people.

Thanks for explaining.

So reason 1 seems specific to the langs that
has more than one input layout. This is not the
case with Cyrillic. With Cyrillic you only have
the layout that is printed on your keyboard and
no short-cuts are needed to switch to another
Cyrillic layout (because this is only needed when
you change your keyboard).

Reason 2 can probably be moved to ibus-wide level.
Is it possible to make a single IM engine to present
itself as multiple engines? So that you can use
ibus-wide hotkeys to switch between the typing modes
of a single engine just as well as between different
engines.

In any case, I am using linux since pre-XKB times,
and all these years long I've never seen RU in an
indicator and still the English typing. I've never
seen it in any other OS either. And now I have to see
exactly that. You'll get bug reports on that, for sure.
If you really want to keep 2 ways of switching to English,
then at least you should update the indicator accordingly,
like something like RU(en). This doesn't make much
of a sense, but at least then there will be no bug
reports and the user will at least see what layout
he currently has.

(In reply to Stas Sergeev from comment #56)
> Reason 2 can probably be moved to ibus-wide level.
> Is it possible to make a single IM engine to present
> itself as multiple engines? So that you can use
> ibus-wide hotkeys to switch between the typing modes
> of a single engine just as well as between different
> engines.

Probably I don't have to move the engine settings to ibus core because the single IME users don't have to use ibus-setup but the engine setup only.

> In any case, I am using linux since pre-XKB times,
> and all these years long I've never seen RU in an
> indicator and still the English typing. I've never
> seen it in any other OS either. And now I have to see
> exactly that. You'll get bug reports on that, for sure.
> If you really want to keep 2 ways of switching to English,
> then at least you should update the indicator accordingly,
> like something like RU(en). This doesn't make much
> of a sense, but at least then there will be no bug
> reports and the user will at least see what layout
> he currently has.

Sorry, I don't catch up whole the discussion.
I just wonder if the engine configuration is needed by ru users since you can add 'us' and 'rusle' in ibus-setup.
Changing icons by engine input modes is still under the discussion.

(In reply to fujiwara from comment #57)
> Probably I don't have to move the engine settings to ibus core because
> the single IME users don't have to use ibus-setup but the engine setup only.
Then perhaps it is possible to make the both setups to
change the same setting? The user then will be able to
use engine setup to change the ibus setting and get the
same results as before. But the ibus-setup users will
immediately benefit from having the shortcuts they defined
to work also for the engine-specific layouts.

> I just wonder if the engine configuration is needed by ru users since you
> can add 'us' and 'rusle' in ibus-setup.
Of course I can't speak for all Russian users.
There is a person who can though:
Sergey Udaltsov <svu>
But I know he doesn't like to speak about ibus. :)

But my opinion is that adding 'us' and 'ru'
(in my case - 'rusle', but most people just use 'ru')
is enough and the engine configuration for this
is not needed. And even if there is, the default
should be set to Disabled.

> Changing icons by engine input modes is still under the discussion.
User has to know and see what his current layout is.
It is simply not possible to display RU and typing as
if it was EN - this will immediately generate a bug report.
Note that I've never seen something like that in any
versions of linux or windows, so on that particular
question I can probably speak about all/most Russian users.

(In reply to Stas Sergeev from comment #58)
> (In reply to fujiwara from comment #57)
> > Probably I don't have to move the engine settings to ibus core because
> > the single IME users don't have to use ibus-setup but the engine setup only.
> Then perhaps it is possible to make the both setups to
> change the same setting? The user then will be able to
> use engine setup to change the ibus setting and get the
> same results as before. But the ibus-setup users will
> immediately benefit from having the shortcuts they defined
> to work also for the engine-specific layouts.
I realize this may be difficult to implement because
then the ibus setup will have to handle the dynamic
set of settings that different engines provide to it.

(In reply to Stas Sergeev from comment #54)
> Could you please point me to the forum
> where users demand that feature because
> of a small delay (or for any other reason)?

Some thing like this?
https://code.google.com/p/ibus/issues/detail?id=1079

Not exactly small delay for machine, but just the key sequence they use to.

(In reply to Ding-Yi Chen from comment #60)
> Not exactly small delay for machine, but just the key sequence they use to.
Exactly!
My point was that the delay is not a problem, something
else is (like a key they want to use).
My suggestion is to just unify that with the ibus config...
or at least update an indicator... or at least disable that
"feature" for ru/rusle. :)

I just want a good decision is made before Mike started
to implement the engine-specific config menu for that.
Engine-specific menu will not solve the problem with an
indicator, but the unification with ibus - will.

Hi Mike, got this crash on gnome startup:

---
factory.py:89:do_create_engine:Exception: Cannot create engine rusle

Traceback (most recent call last):
  File "/usr/share/ibus-table/engine/factory.py", line 81, in do_create_engine
    + str(self.engine_id), self.dbdict[engine_name])
  File "/usr/share/ibus-table/engine/table.py", line 1086, in __init__
    self._config.connect ("value-changed", self.config_value_changed_cb)
AttributeError: 'NoneType' object has no attribute 'connect'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/ibus-table/engine/factory.py", line 89, in do_create_engine
    raise Exception("Cannot create engine %s" %engine_name)
Exception: Cannot create engine rusle

Local variables in innermost frame:
udb: 'rusle-user.db'
path_patt: <_sre.SRE_Pattern object at 0x7f91d0fd83a8>
self: <EngineFactory object at 0x7f91d0f80aa0 (factory+EngineFactory at 0xbac440)>
_sq_db: <tabsqlitedb.tabsqlitedb object at 0x7f91d0f83750>
db_dir: '/usr/share/ibus-table/tables'
traceback: <module 'traceback' from '/usr/lib64/python3.3/traceback.py'>
engine_base_path: '/com/redhat/IBus/engines/table/%s/engine/'
db: '/usr/share/ibus-table/tables/rusle.db'
engine_name: 'rusle'
---

I have all your patches applied, are they making problems?

I don’t think it has anything to do with my recent patches.

Can you give an exact procedure how to reproduce this?

Unfortunately its not reproducable.
I'll let you know if I see it ever again.

Hmm...
Actually, it is now 100% reproducable it seems.
I don't know how to even get rid of it.
The only difference is that now RU somehow
became a default. I.e. when I start gnome, I
immediately see RU. This wasn't the case before,
the default was EN, and I don't know what have
I changed (I didn't change any thing).

So, when it is RU at startup, it then crashes
with that backtrace. But with "ibus restart"
I can't reproduce that.

(In reply to Stas Sergeev from comment #65)
> Hmm...
> Actually, it is now 100% reproducable it seems.
> I don't know how to even get rid of it.
> The only difference is that now RU somehow
> became a default. I.e. when I start gnome, I
> immediately see RU. This wasn't the case before,
> the default was EN, and I don't know what have
> I changed (I didn't change any thing).

Gnome3 remembers what you used last.
So when you used RU last and log out, you will
get RU again when you log in next.

> So, when it is RU at startup, it then crashes
> with that backtrace. But with "ibus restart"
> I can't reproduce that.

I still cannot reproduce this, not even when choosing
rusle, logging out and logging in again to get rusle
by default. It still works for me.


comment#62>     self._config.connect ("value-changed", self.config_value_changed_cb)
comment#62> AttributeError: 'NoneType' object has no attribute 'connect'

That is quite weird. I have no idea how self._config could be “None”
here.

The line directly before that line tries to get it from the bus:

        # config module
        self._config = self._bus.get_config ()
        self._config.connect ("value-changed", self.config_value_changed_cb)

So somehow this “self._bus.get_config ()” must have failed and returned
“None”. That is very strange.

I have not yet made that keybinding configurable, but in
ibus-table-1.9.0 at least the input mode (e.g. rusle or direct
keyboard input) is shown in the input source indicator in the Gnome3
panel.

Looks like this if when in table mode for rusle:

  ☑Р

and like this if it is in direct input mode:

  ☐Р

That should make it more obvious when you are switching between
rusle and direct input.

https://github.com/kaio/ibus-table/releases/tag/1.9.0

https://admin.fedoraproject.org/updates/ibus-table-1.9.0-1.fc20

https://admin.fedoraproject.org/updates/ibus-table-1.9.0-1.fc19

(In reply to Mike FABIAN from comment #66)
> (In reply to Stas Sergeev from comment #65)
> > Hmm...
> > Actually, it is now 100% reproducable it seems.
> > I don't know how to even get rid of it.
> > The only difference is that now RU somehow
> > became a default. I.e. when I start gnome, I
> > immediately see RU. This wasn't the case before,
> > the default was EN, and I don't know what have
> > I changed (I didn't change any thing).
> 
> Gnome3 remembers what you used last.
> So when you used RU last and log out, you will
> get RU again when you log in next.
But this doesn't make too much sense.
I am using a separate per-window layout, so what
is the "layout when I log out"?
Is it possible to disable that "clever" feature and
just get a fixed (configurable) default layout?


> So somehow this “self._bus.get_config ()” must have failed and returned
> “None”. That is very strange.
I think something is just not initialized in time.
A few seconds later it works fine, and you need to
reboot to hit that again (and no, not 100%, just sometimes).

(In reply to Stas Sergeev from comment #68)
> (In reply to Mike FABIAN from comment #66)
> > Gnome3 remembers what you used last.
> > So when you used RU last and log out, you will
> > get RU again when you log in next.

> But this doesn't make too much sense.

I am not sure whether this makes sense or not, it doesn’t bother me,
I don’t really care one way or the other here.

> I am using a separate per-window layout,

That is what I prefer as well.

> so what is the "layout when I log out"?

I just tried it again, it is the input source which was active in the
window which has focus when one logs out.

For example, if I have two windows

    - gnome-terminal, input source rusle
    - gedit, input source translit

When gnome-terminal has focus while I log out, rusle will be the
default when logging in next.

When gedit has focus while I log out, translit will be the default
when logging in next.

> Is it possible to disable that "clever" feature and
> just get a fixed (configurable) default layout?

I don’t know.

> > So somehow this “self._bus.get_config ()” must have failed and returned
> > “None”. That is very strange.
> I think something is just not initialized in time.
> A few seconds later it works fine, and you need to
> reboot to hit that again (and no, not 100%, just sometimes).

I guess it has nothing to do with ibus-table. Maybe
it is an ibus problem?

(In reply to Mike FABIAN from comment #69)
> I just tried it again, it is the input source which was active in the
> window which has focus when one logs out.
But I close all windows before logging out...
Now I'll have to leave one to change the default
back to the sane state. What a silly things.
It could instead remember the per-application
last state - that could have been useful.

> I guess it has nothing to do with ibus-table. Maybe
> it is an ibus problem?
Likely so.
I'll open a separate report.

(In reply to Mike FABIAN from comment #67)
> I have not yet made that keybinding configurable, but in
> ibus-table-1.9.0 at least the input mode (e.g. rusle or direct
> keyboard input) is shown in the input source indicator in the Gnome3
> panel.
Hi Mike, why do you think direct mode is needed
for Russian users? You implemented an indicator
for it, which means you are confident it is needed.
But I think only the russian-i18n expert, like
svu or someone else can say for sure if
this is needed or not. It may be entirely possible
that the work you did on an indicator, will not be
appreciated, unless you ask someone who really knows
what Russian users need.
My opinion is that the direct mode not needed for us.
I may be wrong of course, but at least its worth
asking someone who knows for sure.
Alternatively, disabling it and waiting if someone
thinks it is needed and asks to re-enable it.

(In reply to Mike FABIAN from comment #69)
> (In reply to Stas Sergeev from comment #68)
> > (In reply to Mike FABIAN from comment #66)
> > > Gnome3 remembers what you used last.
> > > So when you used RU last and log out, you will
> > > get RU again when you log in next.
> 
> > But this doesn't make too much sense.
> 
> I am not sure whether this makes sense or not, it doesn’t bother me,
> I don’t really care one way or the other here.
> 
> > I am using a separate per-window layout,
> 
> That is what I prefer as well.
> 
> > so what is the "layout when I log out"?
> 
> I just tried it again, it is the input source which was active in the
> window which has focus when one logs out.
> 
> For example, if I have two windows
> 
>     - gnome-terminal, input source rusle
>     - gedit, input source translit
> 
> When gnome-terminal has focus while I log out, rusle will be the
> default when logging in next.
> 
> When gedit has focus while I log out, translit will be the default
> when logging in next.
> 
> > Is it possible to disable that "clever" feature and
> > just get a fixed (configurable) default layout?
> 
> I don’t know.

Rui Matos tells me that Gnome 3.14 will not remember the input source
used last anymore on the next login:

<rtcm> mfabian: gnome 3.14 now defaults to the first usable input source, this
       is a change from how it worked previously

Hi Mike, he already told me this too:
https://bugzilla.redhat.com/show_bug.cgi?id=1144742
Sadly, there seem to be no updates for 19 or 20...

Mike, just how many direct modes do we have here?
There was already a bug report on direct vs normal
mode. And now we have direct vs table mode...
While the same name, these direct modes seem to have
nothing to do with each other.
This is nothing but to confuse the user. :)

(In reply to Stas Sergeev from comment #74)
> Mike, just how many direct modes do we have here?
> There was already a bug report on direct vs normal
> mode.

That was “direct commit” versus “normal commit”.
As this is only useful for tables which have RULES = ...
to define new shortcuts, I disabled it for tables
which don’t have that (like rusle for example).

It was this commit:

https://github.com/mike-fabian/ibus-table/commit/bbf7d0f3fcb73cb5ec777cb9fee30991fe3fcd53

This is already included in ibus-table 1.9.0

> And now we have direct vs table mode...

Which is something completely different.

> While the same name, these direct modes seem to have
> nothing to do with each other.
> This is nothing but to confuse the user. :)

(In reply to Mike FABIAN from comment #75)
> Which is something completely different.
I know, but why not to choose different names for
something completely different? It only confuses users.
(or just remove it from Russian tables completely)
I know the differences because I was participating in
both reports, but other people are not supposed to
know how much different "direct" modes you have.

(In reply to Mike FABIAN from comment #67)
> I have not yet made that keybinding configurable, but in
> ibus-table-1.9.0 at least the input mode (e.g. rusle or direct
> keyboard input) is shown in the input source indicator in the Gnome3
> panel.
> 
> Looks like this if when in table mode for rusle:
> 
>   ☑Р
> 
> and like this if it is in direct input mode:
> 
>   ☐Р
Come on, Mike, what have you done? :)
It indeed looks exactly like the above, i.e. a
check-box with P, instead of RU!
Well, let me say it is absolutely impossible.
If you change RU, to which we all got used to
for ages (in every OS!), to some P with checkbox,
no one will ever appreciate that.
Not to mention that this check-box is huge, bigger
than P itself! And it can't be checked with mouse.
Let me propose RU. vs RU (i.e. use dot after RU as
an indicator) if you firmly resist to just remove
the entire thing.

IMHO the entire thing can be implemented much better.
My current assumption is that this all is needed
for some chineese, who may want to add just CN
and get all 30 layouts. Maybe this can be done as
some kind of dependencies? Eg, he adds the CN and
gets the list of check-boxes with all the layouts
he may need. He can uncheck a few he won't need
and click OK. And this will add all the needed
engines for him, at ibus level, rather than at
per-engine level. Likewise, the Russian will add
RU and get a list with a single entry - EN. But,
as EN is usually always added initially, he'll get
no dep list at all.

(In reply to Stas Sergeev from comment #77)
> (In reply to Mike FABIAN from comment #67)
> > I have not yet made that keybinding configurable, but in
> > ibus-table-1.9.0 at least the input mode (e.g. rusle or direct
> > keyboard input) is shown in the input source indicator in the Gnome3
> > panel.
> > 
> > Looks like this if when in table mode for rusle:
> > 
> >   ☑Р
> > 
> > and like this if it is in direct input mode:
> > 
> >   ☐Р
> Come on, Mike, what have you done? :)
> It indeed looks exactly like the above, i.e. a
> check-box with P, instead of RU!

It is not

    P U+0050 LATIN CAPITAL LETTER P

it is

    Р U+0420 CYRILLIC CAPITAL LETTER ER

which happens to look (almost) identical in most fonts ☺.

> Well, let me say it is absolutely impossible.
> If you change RU, to which we all got used to
> for ages (in every OS!),

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.

As only 2 characters are allowed and one is needed to show the on/off
mode, only 1 character is left to indicate which table is used.

At least this shows you clearly when the engine is in direct mode
(i.e. off) so I think this is much better then still displaying "ru"
even in direct mode as it was before.  You thought it had stopped
working when you switched to direct mode accidentally with Shift_L,
there was no indication that anything changed only you suddenly got
Latin letters instead of Cyrillic.

> Not to mention that this check-box is huge, bigger
> than P itself! And it can't be checked with mouse.
> Let me propose RU. vs RU (i.e. use dot after RU as
> an indicator) if you firmly resist to just remove
> the entire thing.

Not possible because Gnome allows only 2 characters there.

See: https://bugzilla.gnome.org/show_bug.cgi?id=736667

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

The Chinese engines also switch between on and off, not between
Chinese and a list of layouts.

Almost all Chinese and Japanese input engines have these on and off
modes (off=direct keyboard input).

It may not be useful for rusle, but it is useful even for some
non-Chinese tables.

Should I make a very special exception *only* for rusle?  That does
not seem to make much sense.

The “☑Р”  shows you clearly that you are using your rusle table,
and *not* a Russian xkb keyboard layout which would display “ru”
in the Gnome panel.

I’ll make the hotkey to switch between on and off configurable soon,
then you can disable it if you want and cannot hit it by accident
anymore. So you don’t need to worry about the direct mode.

(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?

> At least this shows you clearly when the engine is in direct mode
> (i.e. off) so I think this is much better then still displaying "ru"
> even in direct mode as it was before.
Correct.
Then how about P (or just whatever) in direct mode,
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...

> The “☑Р”  shows you clearly that you are using your rusle table,
> 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
I know? And how would I add the Russian Legacy xkb layout
and get rid of all the ibus pain? :)

Where should I read about an interaction
between ibus and xkb, to what layout you
switch when engine disables, whether the
configurator adds an xkb layout or IM,
and all the other topics I seem to not
understand?

(In reply to Mike FABIAN from comment #78)
> 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.
Can we then just display the indication of that
"anything"? Eg, if we disabled the engine and got
to EN, we display EN. If we got something else,
we display that. Of course since I don't know what
this "anything" is, I am just guessing. RTFM url
will help.

(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):

https://en.wikipedia.org/wiki/Cangjie_input_method#Keyboard_layout

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 

### Layout
### 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 mode
> > (i.e. off) so I think this is much better then still displaying "ru"
> > even in direct mode as it was before.
> Correct.
> 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
sense there.

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

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

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 table,
> > 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
> I know?

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:

    Input Sources

    English (US)
    Mike’s layout
    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
  most often
- 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 …

Created attachment 943337 [details]
gnome-control-center-region-difference-between-keyboard-layouts-and-input-engines.png

To show you how to distinguish between xkb layouts and input engines.
The entries with gear-wheels are input engines, the entries
without gear-wheels are xkb keyboard layouts.

Thanks Mike, much clearer now!
Your explanations deserve a wiki page actually.

> 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
How about displaying "us" then?
No mapping needed, will not be confused with EN, and,
by being lowercase, will mean a direct mode of some IM.
And on engines that do not enforce a specific layout
you can keep displaying "things".

> It may not be useful for rusle, but it is useful even for some
> non-Chinese tables.
> Should I make a very special exception *only* for rusle?  That does
> not seem to make much sense.
How about configuring this in a table itself?
NEEDS_DIRECT_MODE=yes
or some such.
Even if there are the good uses of that feature, you
need to evaluate how much engines needs it and how much
do not. If there is a reasonable amount of both, then
the switch in the table would make more sense than disabling
it by hands in the menu.

> 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 ...” ☺.
Very simple: it was not there in the configurator.
In either form, nor in xkb, neither in ibus engine.
Now I wonder why it wasn't there in an xkb form...
Do you have it in?

(In reply to Stas Sergeev from comment #84)

> > 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
> How about displaying "us" then?
> No mapping needed, will not be confused with EN, and,
> by being lowercase, will mean a direct mode of some IM.
> And on engines that do not enforce a specific layout
> you can keep displaying "things".

It would still be a very special case for only very few tables.
I’d like to have at least some consistency in ibus-table, not
ever more options and differences which apply only for a few
tables.

> > It may not be useful for rusle, but it is useful even for some
> > non-Chinese tables.
> > Should I make a very special exception *only* for rusle?  That does
> > not seem to make much sense.
> How about configuring this in a table itself?
> NEEDS_DIRECT_MODE=yes
> or some such.

I thought about this already and somehow liked the idea, it is better
than disabling direct mode for all non-Chinese tables because there
are some non-Chinese tables where direct mode seems useful to me.

So this would be better to do on a table by table basis using
such an option.

(In reply to Mike FABIAN from comment #85)
> It would still be a very special case for only very few tables.
> I’d like to have at least some consistency in ibus-table, not
> ever more options and differences which apply only for a few
> tables.
OK, how about displaying RU when enabled and Р with empty
check-box when disabled? Too inconsistent?

Another idea: add explicit config entries in the table
about direct mode indication. If it is not set, use "things"
as a fallback, or something explicitly marking an error, like
'--' - this will force people to add such explicit config
entries or disable the whole thing with NEEDS_DIRECT_MODE=no.

(In reply to Stas Sergeev from comment #84) 
> > 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 ...” ☺.
> Very simple: it was not there in the configurator.
> In either form, nor in xkb, neither in ibus engine.
> Now I wonder why it wasn't there in an xkb form...
> Do you have it in?
In fact, in /usr/share/X11/xkb/symbols/ru I can see this:
---
partial alphanumeric_keys
xkb_symbols "typewriter-legacy" {
    include "ru(common)"
    name[Group1]= "Russian (typewriter, legacy)";
---

But in the configurator I don't see it.
Mike, can you confirm?
I'll spawn another but then.

Created attachment 944448 [details]
russian-typewriter-legacy-selectable-in-gnome-control-center-f21.png

Stas, comment#87> In fact, in /usr/share/X11/xkb/symbols/ru I can see this:
Stas, comment#87> ---
Stas, comment#87> partial alphanumeric_keys
Stas, comment#87> xkb_symbols "typewriter-legacy" {
Stas, comment#87>     include "ru(common)"
Stas, comment#87>     name[Group1]= "Russian (typewriter, legacy)";
Stas, comment#87> ---
Stas, comment#87> 
Stas, comment#87> But in the configurator I don't see it.
Stas, comment#87> Mike, can you confirm?

“Russian (typewriter, legacy)” is selectable in gnome-control-center
in f21 (I guess in f19 as well, I’ll check in a minute ...)

But this is not the same layout as your rusle table.

(In reply to Mike FABIAN from comment #88)
> 
> “Russian (typewriter, legacy)” is selectable in gnome-control-center
> in f21 (I guess in f19 as well, I’ll check in a minute ...)

No, it is not listed by gnome-control-center in f19 and f20.

(In reply to Mike FABIAN from comment #89)
> (In reply to Mike FABIAN from comment #88)
> > 
> > “Russian (typewriter, legacy)” is selectable in gnome-control-center
> > in f21 (I guess in f19 as well, I’ll check in a minute ...)
> 
> No, it is not listed by gnome-control-center in f19 and f20.

But even if it is not listed in gnome-control-center, you can try
it out by typing

    setxkbmap 'ru(typewriter-legacy)'

in a terminal.

Try it and type something, it is different from the layout of your rusle table,
so I am not sure that this is the layout you want.

(In reply to Mike FABIAN from comment #90)
> Try it and type something, it is different from the layout of your rusle
> table,
> so I am not sure that this is the layout you want.
I'll try that ASAP.
In a mean time maybe you can fill in a bug-report about
why it is not showing in g-c-c. :)

(In reply to Stas Sergeev from comment #91)
> (In reply to Mike FABIAN from comment #90)
> > Try it and type something, it is different from the layout of your rusle
> > table,
> > so I am not sure that this is the layout you want.
> I'll try that ASAP.
> In a mean time maybe you can fill in a bug-report about
> why it is not showing in g-c-c. :)

Well, it happens to show in g-c-c in Fedora 21 Beta.
But I guess that showing it is an accident. g-c-c tries
to show only layouts which are commonly used, as far as I know.
There are very many obscure xkb layouts which probably (almost)
nobody uses, g-c-c apparently wants to keep the list shown short
by showing only common ones.

(In reply to Stas Sergeev from comment #91)
> (In reply to Mike FABIAN from comment #90)
> > Try it and type something, it is different from the layout of your rusle
> > table,
> > so I am not sure that this is the layout you want.
> I'll try that ASAP.
> In a mean time maybe you can fill in a bug-report about
> why it is not showing in g-c-c. :)

Looking at the layouts in /usr/share/X11/xkb/symbols/ru, 
it seems to me that none of the layouts there is the same as
your rusle table.

Looking at

https://en.wikipedia.org/wiki/Keyboard_layout#Russian

I cannot find anything which looks 100% like your rusle table either.

(In reply to Mike FABIAN from comment #92)
> (In reply to Stas Sergeev from comment #91)
> > (In reply to Mike FABIAN from comment #90)
> > > Try it and type something, it is different from the layout of your rusle
> > > table,
> > > so I am not sure that this is the layout you want.
> > I'll try that ASAP.
> > In a mean time maybe you can fill in a bug-report about
> > why it is not showing in g-c-c. :)
> 
> Well, it happens to show in g-c-c in Fedora 21 Beta.
> But I guess that showing it is an accident. g-c-c tries
> to show only layouts which are commonly used, as far as I know.
> There are very many obscure xkb layouts which probably (almost)
> nobody uses, g-c-c apparently wants to keep the list shown short
> by showing only common ones.

Looks like I was mistaken here and not showing these layouts was a bug
in Gnome in f19 and f20, Takao Fujiwara tells me it was a bug which
has apparently been fixed in f21.

Created attachment 944487 [details]
legacy layout

(In reply to Mike FABIAN from comment #93)
> I cannot find anything which looks 100% like your rusle table either.
Mine should match this one:
https://upload.wikimedia.org/wikipedia/commons/0/04/Keyboard_layout_ru%28typewriter%29.svg

Also attached a screen-shot from F17 configurator,
where everything worked just wonderfully!
In F19 I can't get such a good layout display.

(In reply to Mike FABIAN from comment #94)
> Looks like I was mistaken here and not showing these layouts was a bug
> in Gnome in f19 and f20, Takao Fujiwara tells me it was a bug which
> has apparently been fixed in f21.
But F21 is not yet released.
How about a fix for 19/20?

(In reply to Stas Sergeev from comment #95)
> Created attachment 944487 [details]
> legacy layout
> 
> (In reply to Mike FABIAN from comment #93)
> > I cannot find anything which looks 100% like your rusle table either.
> Mine should match this one:
> https://upload.wikimedia.org/wikipedia/commons/0/04/
> Keyboard_layout_ru%28typewriter%29.svg
> 
> Also attached a screen-shot from F17 configurator,
> where everything worked just wonderfully!
> In F19 I can't get such a good layout display.

Your attached legacy layout and the keyboard shown
on the wikipedia link are not identical!

Many special characters like ()_!#-… are on different keys.

As far as cyrillic characters are concerned, the ёЁ characters are
on different keys, they are above the TAB key in your attached legacy
layout but next the left Shift key on your wikipedia link (where your
attached legacy layout has ? and /).

Your rusle table is not identical to either of the above
two layouts.

Your rusle is close to the attached legacy layout,
all Cyrillic characters are on the keys but they
differ in some special characters.

For example, * and ; are exchanged between
the attached legacy layout and your rusle.

rusle has ; on the 4-key and * on the 8-key,
the legacy layout has this reversed.

The layout shown on your Wikipedia link has _ on the 8-key and " on
the 4-key (and many other differences in non-alphanumeric characters).

(In reply to Stas Sergeev from comment #95)
> Created attachment 944487 [details]
> legacy layout
…
> Also attached a screen-shot from F17 configurator,
> where everything worked just wonderfully!
> In F19 I can't get such a good layout display.

The layout you attached here from F17 is 'ru(legacy)'
(It is *not* 'ru(typewriter-legacy)'!).

You can get that layout on f19 and f20 by typing

    setxkbmap 'ru(legacy)'

in a terminal.

You just cannot select it in “gnome-control-center region” because
gnome-control-center had that bug in f19 and f20 not listing some
important layouts.

(In reply to Mike FABIAN from comment #98)
>
> You can get that layout on f19 and f20 by typing
> 
>     setxkbmap 'ru(legacy)'
> 
> in a terminal.
> 
> You just cannot select it in “gnome-control-center region” because
> gnome-control-center had that bug in f19 and f20 not listing some
> important layouts.

Although you cannot select it in “gnome-control-center region”
in f19 and f20 because of that bug, you can still get
it into  the gnome-panel using gsettings or dconf.
I got that hint from Takao Fujiwara:

<fujiwarat> It seems to work to run gsettings in org.gnome.desktop.input-sources
            sources by manual for variants.

<fujiwarat> I tried to add "('xkb', 'us+dvorak')".

I.e. you can type the following in a terminal:

    dconf write /org/gnome/desktop/input-sources/sources "[('xkb', 'us'), ('xkb', 'ru+legacy')]"

This puts the US layout and the Russian legacy layout into the gnome panel.

(Type it exactly as above or better cut&past, note that it is
"ru+legacy" there, not "ru(legacy)").

Thanks Mike!
If you find some differences between mine and what
was attached, they should be regarded as bugs I guess.
The intention was to replicate what I have in F17,
no matter what wikipedia says.
But I'll double-check your findings to be sure.

I only found a single mentioning of that layout:
http://www.infocity.kiev.ua/other/content/other064_01.phtml
http://www.infocity.kiev.ua/other/content/images/other06418.gif
It is absolutely ungooglable to me, origins are unclear.

The more googlable layout is mentioned here:
http://www.odesigne.com/statii_/gosty_osty/111-raskladki-klaviatury..html
http://www.odesigne.com/uploads/posts/2008-03/1204811938_3.gif
It differs from F17's in just a couple of keys (most notably Ё).

Unfortunately I've already dumped my old stuff a couple
of years ago, but I'll try to contact people who still
have such keyboards...

But now I've recalled something else, namely, I made
rusle not from the F17's legacy, but instead from the
/lib/kbd/keymaps/i386/qwerty/ru2.map.gz
F17 was not immediately available to me at that moment,
and I thought F17's xkb layout matches ru2.map.gz.
It appears not...

(In reply to Mike FABIAN from comment #99)
> I.e. you can type the following in a terminal:
> 
>     dconf write /org/gnome/desktop/input-sources/sources "[('xkb', 'us'),
> ('xkb', 'ru+legacy')]"
Thanks!!!!
Finally. :)
That really works.
I have nevertheless opened this ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1150199
so that others can benefit without installing f21-alpha.

Legacy layout:
http://ru.pc-history.com/wp-content/uploads/ok-keyboard_xt-at1.jpg
So I am not sure what was this ru2.map.gz about.
rusle is therefore currently incorrect.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Move to Fedora 23.

Move to Fedora 24

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Move to F30.

I have recently made the hotkeys configurable for ibus-typing-booster,
I will start doing this for ibus-table as well soon.

I made the hot keys configurable in ibus-table 1.11.0:

https://github.com/kaio/ibus-table/releases/tag/1.11.0

Currently it is only possible using the command line though.

I am almost finished rewriting the setup tool to make it possible to configure the hotkeys with a GUI.

In ibus-table 1.12.0, the hotkeys can be configured with a GUI now:

https://github.com/mike-fabian/ibus-table/releases/tag/1.12.0