GNOME Bugzilla – Bug 80585
impossible to enter cyrillic
Last modified: 2006-02-13 07:27:38 UTC
I've tried using gkb to switch the kbd to Cyrillic (Russian) and found it to be almost impossible. gkb provides 3 Russian modes: Russian xkb, Russian xmodmap and Russian Cyrillic (?). I tried all 3 - and in all 3 of them, I am still getting English, not Russian: key "w" produces "w", not "cyrillic_tse". I finally found a way to type Russian - by reading the file /usr/X11R6/lib/X11/xkb/symbols/ru and figuring from it what key acts as mod_switch (I am not telling you which). But surely we can't expect all users of GNOME 2 to do it this way. Also: "Russian xkb" and "Russian xmodmap" kbd files contain "Codepage: iso-8859-1" which is clearly nonsense.
Shooby: any ideas on this one?
I plan to support "variants". /usr/X11R6/lib/X11/xkb/symbols/ru contains 4 variants. You can make a new layout with editing the Russian xkb mode: write "setxkbmap ru [variant]" like "setxkbmap ru phonetic" and try the new layout out. You will find the variants by "grep xkb_symbols /usr/X11R6/lib/X11/xkb/symbols/ru" command. Variants is a new and interesting feature requirement, needs some coding and new format for prep (layout descripting) files. That feature will bring more than 100 new layout for GKB, so I'm going to make this. The codepage field is unused and informal, I will remove it because pang-o can't use it the was as I wanted so.
One other hint from Mantas K. <monte@mail.lt>: grep name /usr/X11R6/lib/X11/xkb/symbols/ru There is two "name group" in the file. So you will have to set this combination by adding this line in XF86Config keyboard section: Option "XkbOptions" "grp:shift_toggle" Or use the command: setxkbmap -option grp:shift_toggle ru in GKB.
I do not know enough about variants, so I can't comment here. But the problem seems to be that "/usr/X11R6/lib/X11/xkb/symbols/ru" contains 2 groups, Cyrillic and English - and it is the English one that is used by default. So to get Cyrillic, you need to toggle groups *after* setxbdmap ru command. I know that - but my father (or almost any person without knowledge of internals of X11) wouldn't; he'd expect that once you have selected "Russian" in GKB, you'll immediately get Cyrillic. And I think this is the way GKB should work - no grepping symbols file to see the list of groups, no editing XF86Config. May I suggest a way to achieve this? Create our own symbol file, based on /usr/X11R6/lib/X11/xkb/symbols/ru, but which has Cyrillic as the first (default) group, and modify the GKB command to be "setxbmap /path/to/our/file". Do you think it will work? Creating the modified file is trivial, but I do not know much about syntax of setxkbmap command. Of course, the same can be done for all other non-iso8859-1 layouts.
Created attachment 8432 [details] ru.xmm
I made an xmodmap file for you. See previous attachment. Usage: xmodmap ru.xmm (in GKB's command field :)))) привет александер!
Thnaks - I'll test this. Will you include it in the next release? As I said, I can solve my kbd problems, but I'd really like GKB to work "out of the box" for other users - such as my father.
Shooby: So is there a fix to make this work out of the box?
Shooby put in a possible fix that is in cvs right now, but didn't quite make it into the 1.102.0 release. Alexander: Could you test with the latest cvs version?
Okay, there is a 1.102.1 relase avaiable that should be included with beta4 to be released soon, and that has these changes.
I have problems building from CVS - but I did test the ru.xmm file (manually, by typing xmodmap /path/to/ru.xmm). Works fine in GNOME2 - except that Shooby forgot to switch groups for number keys, so Shift+6 gives "^" instead of ",". And Caps Lock is not working anymore - this, IIRC, is an old problem with using xmodmap. But this I can live with. I think that other language users might also be interested in getting kbd layouts that do not require them to hold down AltGr key - maybe worth asking on i18n mailing list. But I do not really care.
Shooby's fix is in the beta5 release. Alexander: can you test if gkb now works "out of the box" without using the patch attached to this bug?
Y¤s, works out of th¤ box for m¤ now Still has som¤ probl¤ms: for ¤xampl¤, aft¤r switching to Plain Russian K¤ymap and th¤n back to US ¤nglish, I can't typ¤ l¤tt¤r ¤, cant typ¤ p¤riod, I g¤t backslash inst¤ad of dash, ¤tc
Could you make a proper cyrillic keymap? Please help me and send me your corrected version if you can. Thank you.
It seems that ru-rev.xmm file is mostly OK (it only needs swapping groups for number keys - I'll send you the patch) - I have no problems typing Cyrillic letters. The problems start when I try to switch back to US English kbd - and I have no idea why. Maybe because "Plain Russian Kbd" uses xmodmap and "English (US)" uses xkb? Just guessing... I'll ask people on gnome-cyr mailing list for help - there are people there who know much more than I do. `
The problem is that gkb applet doesn't have ability to switch beetween xkb groups. There is another gnome applet, which can switch beetween xkb groups - gswitchit (see http://gswitchit.sf.net) I think gkb and gswitchit should merge and xkb-related stuff should be done with library from gswitchit - http://gswitchit.sourceforge.net/libxklavier/doc/ Then will be no problems with gkb and xkb keymaps. (xmodmap related stuff can stay as it is now)
There is a problem with xkb extension. Sun X server does not support it IMHO. Please correct me if I'm wrong. I think there is a solution to build gkb with libxklavier platform dephendently, but I need help (patches, etc) because I have to time and hardware to test it.
Guys, I think the better idea (IMHO) would be not share but split responsibility. gkb would be the help for xmodmap-oriented people (who are unfortunate enough to miss XKB extension). And gswitchit already handles xkb much better than gkb (sorry, not really humble but still true) - so leave xkb to it. Soon gswitchit is going to be moved into gnome cvs - so it would be under the gnome umbrella... Is all this bad idea ?
hello, let me ask because I'm not quite sure I do follow properly the thread. how this is this going to be fixed? I got keyboard layout working nice after replacing the places latin-cirillic in gkb_xmmap file. is that about the same issues? -- fikin
Yes and No. It is all about XKB Xfree extension that lets one have a true international keyboard, allows setting XFree wide hotkeys for switching keyboard layouts and stuff. GKB is almost unusable for the languages that do not use Latin alphabet. Languages like Russian, Bulgarian, Ukrainian, Armenian, Georgian etc. etc. require a separate keyboard layout which has no room for latin letters (used for inputting system commands, mathematical variables and such). Many tasks make the user switch keyboards rather often, so there must be a simple hotkey, an indikator in the panel and a complex configuration backend. Gswitchit provides it all while gkb functionality is not enough. (This was an answer for the previous post)
I plan to write a small utility what can switch between xkb layouts, variants and groups (like setxkbmap, but with group switching support). I need help, I have no time to learn how to use xkb (since I have to work hard for my salary :)) This can solve most of the problems. If you have time and want to help please contact me. ...---...
How different will it be from gswitchit? What extra functions do you want to put in it? I could help you with xkb - and my libxklavier can be of some help here.
So we can start discussions here - or just write me privately...
This will be a command line utility (good for scripting and bug squashing, emergency switching, too) I plan it as simple as it can be. Gswitchit is just for xkb and there are lot of users who cannot use xkb because they have unsupported layouts (unsupported by XFree86, like indic project) or they have to hold down the key Alt to type their specific characters and they dont want to do that. So they send me their special keymap in xmodmap format and I include this in gkb. XFree86 project is bigger and slower.
Maintaining/supporting/shipping different keymaps in different places with different projects as it is done now doesn't make any sense. XFree86 is very much opening nowdays with promises of more frequent or even modular releases. There is a bugtracker http://bugs.xfree86.org/ Thereis an open development list. http://xfree86.org/mailman/listinfo/devel. This simply should be fixed in the right place.
Please - let's not duplicate the effort of XFree in layout making. They probably are not the fastest - but they already got established infrastructure. With latest xkb modifications (in xfree 4.3.0) - I think the effort should be put to enlarging the xkb configuration repository of xfree - but not forking/duplicating it. At least let's discuss this serious matter at desktop mailing list (though I am not even sure it is worth discussing - from my point of view, it would be just very bad thing to do). About the utility: what could be the scenarios of its invocation? Will it be some kind of daemon - or just some quick execution (like setxkbmap)? For xkb case - how is it going to deal with 4-group limitation (if it just going to switch groups)?
I think this report has strayed from it's original subject. Can we close this and reopen bugs for specific areas that need work instead? It's hard to track a bug that is as general as this.
Is there any action on this bug?
Yes, this "bug" is final agony of GKB. I have rewritten GKB with every big version change of Gnome. I still got lots of feature reguests (new and corrected keymaps) and fixes for official keyboards. Since Sergey is working to replace GKB I decided to not stop him, I decided to not rewrite GKB again. Maybe this is the best for the community. Tell me if I am wrong about this, I'm extremely since I saw my work is against others will.
Now, gswitchit is fully integrated. The only problem we have is X servers without xkb extension. I would highly appreciate Szabolics' help and support in this area. For now, x servers without xkb show good old gkb - so it would be cute to give it some HIG love, de-flagize it etc.