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
