[Fedora-i18n-bugs] [Bug 1133127] New: The hotkey for switching to direct input mode should be configurable
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Bug ID: 1133127 Summary: The hotkey for switching to direct input mode should be configurable Product: Fedora Version: 19 Component: ibus-table Assignee: mfabian@redhat.com Reporter: stsp@list.ru QA Contact: extras-qa@fedoraproject.org CC: dchen@redhat.com, extras-qa@fedoraproject.org, i18n-bugs@lists.fedoraproject.org, kent.neo@gmail.com, me@kaio.net, mfabian@redhat.com, pwu@redhat.com, shawn.p.huang@gmail.com, stsp@list.ru
+++ This bug was initially created as a clone of Bug #1128912 +++ (In reply to Stas Sergeev from comment #23)
I noticed another problem. When I type, the layout ocasionally changes back to EN, even though I do not press the modifier combo. The switcher applet still shows RU, but the typing becomes latinic. Presumably this happens after Shift-Space, but again, not always... So we have another puzzle. I wonder if you can make a sharp guess or reproduce that...
You are switching between table mode ("rusle") and direct input mode (using the underlying keyboard layout directly).
The hotkey for this is the left shift key (Without space, just left shift and release it).
You can see which mode you are in if you open the input method menu in the gnome panel while rusle is active. Look at the 4 menu entries near the bottom:
Direct input (Left Shift) Phrase mode (Ctrl-;) <- quite useless for rusle Direct commit mode (Ctrl-/) <- quite useless for rusle Setup
If you hit the left shift key and look again, you see that the topmost of these "property" menus toggles between
Direct input (Left Shift) <-> Р (Left Shift)
I am not sure what I can do about this now.
For Chinese, this is used often as a quick way to toggle between Chinese and English mode (faster than switching between two input sources). That might be the reason why the original developer of ibus-table did choose the left shift key as the hot key for that.
The disadvantage is of course that the left shift key can be hit far too easily.
In the long run, I want to make the keybindings configurable, then you could set that keybinding to empty. But I have no time for that soon, that is a bit more work.
Choosing a different shortcut is not nice to existing users.
Disabling that shortcut for non-CJK input methods might also be not so nice. Maybe one wants to quickly toggle between direct input and a non-CJK input method as well.
So I am a bit puzzled what to do about this now.
Maybe wait until I have time to make the keybindings configurable?
--- Additional comment from Stas Sergeev on 2014-08-22 15:32:52 EDT ---
Maybe wait until I have time to make the keybindings configurable?
Maybe I have no other option than to agree with this? :) Anyway, another sharp guess, you are right, left shift is the culprit. Thank you.
So, should I open a separate report for this or what?
--- Additional comment from Stas Sergeev on 2014-08-22 15:34:22 EDT ---
(In reply to Mike FABIAN from comment #24)
Created attachment 929759 [details] 0001-Ignore-Shift-Space-hotkey-to-switch-fullwidth-halfwi.patch
To fix the problem in comment#21
Patch tested and works.
--- Additional comment from Mike FABIAN on 2014-08-22 15:55:18 EDT ---
(In reply to Stas Sergeev from comment #26)
Maybe wait until I have time to make the keybindings configurable?
Maybe I have no other option than to agree with this? :) Anyway, another sharp guess, you are right, left shift is the culprit. Thank you.
So, should I open a separate report for this or what?
Yes, I think a separate bug report is helpful so I do not forget this.
Maybe, as a temporary workaround, I disable that hotkey for non-CJK and enable it again as soon as the hotkeys are configurable.
I really should make the hotkeys configurable ...
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #1 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #2 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #3 from Mike FABIAN mfabian@redhat.com ---
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #4 from Mike FABIAN mfabian@redhat.com --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #5 from Stas Sergeev stsp@list.ru --- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #6 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #7 from Stas Sergeev stsp@list.ru --- 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!
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #8 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #9 from Stas Sergeev stsp@list.ru --- You still need xine playing in the background, otherwise you can't reproduce in any way. Yes, that sounds silly, but is true.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #10 from Mike FABIAN mfabian@redhat.com --- Is comment#6 and comment#7 the same problem or are these different problems?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #11 from Stas Sergeev stsp@list.ru --- Hi, they are different. To not pollute this bug, I opened https://bugzilla.redhat.com/show_bug.cgi?id=1134299 for comment #6.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #12 from Mike FABIAN mfabian@redhat.com --- Thank you!
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #13 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #14 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #15 from Mike FABIAN mfabian@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #16 from Mike FABIAN mfabian@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #17 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #18 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #19 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #20 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #21 from Mike FABIAN mfabian@redhat.com --- (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).
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #22 from Stas Sergeev stsp@list.ru --- (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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #23 from Mike FABIAN mfabian@redhat.com --- (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:
- 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/9f4218ca58bbca1eb020579ee98...
This patch should apply to your version of ibus-table.
- 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”.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #24 from Mike FABIAN mfabian@redhat.com --- 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”).
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #25 from Mike FABIAN mfabian@redhat.com --- Also reproducible using gedit while xine is running.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #26 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #27 from Mike FABIAN mfabian@redhat.com --- 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!
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #28 from Mike FABIAN mfabian@redhat.com --- (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 terminalFrom time to time, Shift_L and Control_L events are coming!
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #29 from Stas Sergeev stsp@list.ru --- Do you mean, its an Xorg bug, not even ibus?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #30 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #31 from Mike FABIAN mfabian@redhat.com --- I opened this bug against xine:
https://bugzilla.redhat.com/show_bug.cgi?id=1134406
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #32 from Stas Sergeev stsp@list.ru --- 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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #33 from Mike FABIAN mfabian@redhat.com --- I cannot reproduce this at the moment. If you have any more details on how to reproduce it, this would ge great.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #34 from Mike FABIAN mfabian@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #35 from Mike FABIAN mfabian@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #36 from Mike FABIAN mfabian@redhat.com --- 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".
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #37 from Mike FABIAN mfabian@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #38 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #39 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #40 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #41 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #42 from Stas Sergeev stsp@list.ru --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #43 from Stas Sergeev stsp@list.ru --- Moved unrelated discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1135759
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #44 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #45 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #46 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #47 from Stas Sergeev stsp@list.ru --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #48 from Stas Sergeev stsp@list.ru --- I mean, there are the configurable short-cuts to select between EN and RU, so why also the hardcoded one?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #49 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #50 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #51 from Stas Sergeev stsp@list.ru --- I understand that this is "somewhat" different. One is switching the engine, other is not. But for the end-user - what's the difference?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #52 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #53 from Mike FABIAN mfabian@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #54 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
fujiwara tfujiwar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tfujiwar@redhat.com
--- Comment #55 from fujiwara tfujiwar@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #56 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #57 from fujiwara tfujiwar@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #58 from Stas Sergeev stsp@list.ru --- (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@gnome.org 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #59 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #60 from Ding-Yi Chen dchen@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #61 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #62 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #63 from Mike FABIAN mfabian@redhat.com --- I don’t think it has anything to do with my recent patches.
Can you give an exact procedure how to reproduce this?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #64 from Stas Sergeev stsp@list.ru --- Unfortunately its not reproducable. I'll let you know if I see it ever again.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #65 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #66 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #67 from Mike FABIAN mfabian@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #68 from Stas Sergeev stsp@list.ru --- (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).
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #69 from Mike FABIAN mfabian@redhat.com --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #70 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #71 from Stas Sergeev stsp@list.ru --- (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@gnome.org 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rmatos@redhat.com
--- Comment #72 from Mike FABIAN mfabian@redhat.com --- (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 translitWhen 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
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #73 from Stas Sergeev stsp@list.ru --- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #74 from Stas Sergeev stsp@list.ru --- 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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #75 from Mike FABIAN mfabian@redhat.com --- (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/bbf7d0f3fcb73cb5ec777cb9fee...
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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #76 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #77 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #78 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #79 from Stas Sergeev stsp@list.ru --- (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? :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #80 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #81 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #82 from Mike FABIAN mfabian@redhat.com --- (In reply to Stas Sergeev from comment #79)
(In reply to Mike FABIAN from comment #78)
If you use a keyboard layout, yes. This is an input engine, (ab)used to emulate a keyboard layout.
But that is a very special case for rusle, almost all other tables are really input engines, not keyboard layouts.
And for them, switching into direct mode does not switch to "en" but to some unknown keyboard layout which was used before, i.e. the engine can be toggled between on ☑ and off ☐. In “off” mode it does not have to be US keyboard layout, it can be anything.
What exactly is anything? How to control that?
Let’s say we use the ibus-kkc engine, a Japanese input engine. It transliterates Latin input to Japanese hiragana, e.g.
ya → や
and then one can convert it to kanji etc.
ibus-kkc does not enforce a keyboard layout, which keyboard layout is used depends on which was used last.
Now assume we have 3 input sources in the Gnome panel:
de (German keyboard layout) us (US English keyboard layout) kkc (Japanese input engine)
Select “us”, then “kkc”, in that case kkc will use the US keyboard layout, i.e. to type “ya” and get it converted to や you have to type the key to the right of the left shift key and then the key to the right of the capslock key.
Now select “de” and then select “kkc” again. Now “kkc” uses the German keyboard layout!
That means if you press the same 2 keys now which gave you “ya” on the US layout, you will get “za” instead which kkc transliterates to ざ. That is good, there is no reason to force a specific layout for kkc, any layout which can input Latin letters is just fine.
If one switches to direct mode in kkc, the direct mode may behave like a German keyboard layout or like a US English keyboard layout depending on what was selected last before switching to kkc.
Engines which do transliteration like kkc (or the Russian translit table) can usually work with any keyboard layout, so they do not enforce a special layout when switching to them. In such engines, the direct mode uses whatever keyboard layout was selected last before switching to that engine.
However, there are also engines which depend on a specific keyboard layout. Some Chinese engines which are not transliterating but have “radicals” (components of Chinese characters) on certain keys need to enforce a specific keyboard layout. One example is the Cangjie input method (also supported by ibus-table):
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 …
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #83 from Mike FABIAN mfabian@redhat.com --- Created attachment 943337 --> https://bugzilla.redhat.com/attachment.cgi?id=943337&action=edit 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #84 from Stas Sergeev stsp@list.ru --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #85 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #86 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #87 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #88 from Mike FABIAN mfabian@redhat.com --- Created attachment 944448 --> https://bugzilla.redhat.com/attachment.cgi?id=944448&action=edit 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #89 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #90 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #91 from Stas Sergeev stsp@list.ru --- (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. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #92 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #93 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #94 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #95 from Stas Sergeev stsp@list.ru --- Created attachment 944487 --> https://bugzilla.redhat.com/attachment.cgi?id=944487&action=edit 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%28typ...
Also attached a screen-shot from F17 configurator, where everything worked just wonderfully! In F19 I can't get such a good layout display.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #96 from Stas Sergeev stsp@list.ru --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #97 from Mike FABIAN mfabian@redhat.com --- (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).
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #98 from Mike FABIAN mfabian@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #99 from Mike FABIAN mfabian@redhat.com --- (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)").
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #100 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #101 from Stas Sergeev stsp@list.ru --- 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...
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #102 from Stas Sergeev stsp@list.ru --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #103 from Stas Sergeev stsp@list.ru --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #104 from Fedora End Of Life endoflife@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|19 |21
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
--- Comment #105 from Fedora End Of Life endoflife@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|21 |23
--- Comment #106 from Mike FABIAN mfabian@redhat.com --- Move to Fedora 23.
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|23 |24
--- Comment #107 from Mike FABIAN mfabian@redhat.com --- Move to Fedora 24
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|24 |rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Satyabrata Maitra smaitra@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |i18n
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Mike FABIAN mfabian@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|27 |28
i18n-bugs@lists.fedoraproject.org
-
bugzilla＠redhat.com -
Red Hat Bugzilla