Deniz Akkus Kanca wrote: > I'd like to chime in and say that the changes proposed by Nilgün fix the > problems we have with Turkish/X/xkb capslock. > > Every single Turkish user of Linux installs a distrib, finds out they > have problems using the Turkish keyboard and turns to the LUG mailing > list where we tell them this solution. > > It really would make life a lot easier if this could be merged into the > regular distribution.
Regarding your question in the subject line an answer, I suppose, is 'no'. Nilgün wrote: > We need a symbolic link for locale directories under /usr/lib/locale: > > ln -s tr_TR.utf8 tr_TR.UTF-8 It makes sense for a 'system locale' and has no relation to the XFree locales. An XFree's locale/locale.dir file already has a record en_US.UTF-8/XLC_LOCALE: tr_TR.UTF-8 which do the same for the XFree. Nilgün wrote: > /etc/X11/XF86Config file needs following mods: > > Section "InputDevice" > > Identifier "Keyboard1" > Driver "Keyboard" > Option "AutoRepeat" "500 30" > Option "XkbRules" "xfree86" > Option "XkbModel" "pc105" > Option "XkbLayout" "tr" > Option "XkbOptions" "grp_led:caps" > > EndSection It can be a suggestion in your HOWTO but can't be changes for the distributive. Nilgün wrote: > For users of Turkish Q keyboard: > > cp tr_q tr > > For users of Turkish F keyboard: > > cp tr_f tr How do you imagine the corresponded changes (patches) for the disributive? Do you want one of these files be replacement for the 'tr' file? Of course, your LUG can offer new keyboard maps and they will be accepted but you should prepare a patch which adds both of files to the xkb/symbols directory or (it would be better) both maps as an 'xkb variants' in one single file 'tr'. And don't forget to add descriptions for new maps into the xkb/rules/xfree86.lst file. Nilgün wrote: > /etc/X11/xkb/compat/iso9995 file needs following mods: > > interpret ISO_Next_Group { > useModMapMods= level1; > virtualModifier= AltGr; > - action= LockGroup(group=+1); > + action= LockGroup(group=+2); > }; > > interpret ISO_Prev_Group { > useModMapMods= level1; > virtualModifier= AltGr; > - action= LockGroup(group=-1); > + action= LockGroup(group=-2); > }; It is a most disturbing part. Do you suppose a ISO_Next_Group and a ISO_Prev_Group keysyms are needed for Turkish users only and such changes won't disturb anybody in the world? Actually these keysyms are used in all keyboard maps which contain non-latin alphabets (Cyrillic, Hebrew, Greek, etc.) and changing their actions will confuse many people. By the way, you offer a big 'multi-floor' map when your problem could be solved in simpler way. I'd suggest you return to the 'caps:*' options using. I composed those options specilay for your problem solution. I know it doesn't work now. It's my fault. I missed that an xkbcomp marks non-ascii keysym keys as having a "TWO_LEVEL" type so they are not affected by the CapsLock modifier at all. And we need to specify the ALPHABETIC type for such keys explicitly. For example key <AD08> { type[group1] = "ALPHABETIC", [ idotless, I ] }; I have attached the 'tr' map where this problem is fixed. And I have checked it just now. It works. Please, try it. It could be solution which doesn't disturb other users and requires less changes in the keyboard maps. In summary, you need - use that corrected keyboard map - add the caps:shift to the XkbOptions option (Option "XkbOptions" "grp_led:caps,caps:shift") - and if you have XFree older than 4.2.0 you need to set couple of environment variables: _XKB_OPTIONS_ENABLE=on _XKB_CONSUME_LOOKUP_MODS=on By the way, all users who want a 'Shift cancels Caps' mode had to set these variables too. But in 4.2.0 they are setted by default. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia
tr.gz
Description: ../tr.gz