Re: [I18n]Wrong Scan Codes in Turkish (ISO-8859-9) Keyboard
> Hi, > > Below is a bug report that I have submitted to RedHat and they adviced > me to sent to you: > > > Description of problem: > 2 of the ISO-8859-9 (Turkish) glaphys are displayed wrong when the > CAPSLOCK > key is on. (Using "tr" keyboard layout in XConfig-4) See a thread "Problem with Caps-lock /Shift combo's in xkb - locale tr" in June archive of this list. The first message http://www.xfree86.org/pipermail/i18n/2001-June/002074.html -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Why "Keyboard: CustomKeycode disabled" ???
> This is a good idea, it can be added to .xinitrc, but doesn't solve the whole > problem. It seems like it only forces a valid keymap source to be merged with > the XKB settings (not re-loaded: old key types remain, I have not tested > conflicting key type definitions, but it should work). Yes. By default new keymap is added with 'merge' mode. You can change this mode to 'replace' by some tricks but anyway the XKB doesn't remove types absent in new keymap but only adds or changes types with the same names. > The fact is, the "XkbKeymap" option in XF86Config is working, to the extent > that it loads my custom map. I just tried to run X's simple Tab Window > Manager and suddenly my keymap was sort of working (still needs quite some > improvement). So I removed the ~/.kde/share/config/kxkbrc that was basically > re-loading the gb(pc105) keyboard layout and now KDE behaves like TWM. It's also true. If you want to use own customized keymap you need to switch off kxkb program. > So it seems that the warnings/errors in the X Server log: > > (**) XKB: keymap: "uk_iso" (overrides other XKB settings) > (==) Keyboard: CustomKeycode disabled > [...] > (II) Initializing built-in extension XKEYBOARD > [...] > (II) Keyboard "My Keyboard" handled by legacy driver > > are not really the problem. To tell you the truth, now I cannot get rid of > these even going back to all the original XKB files, although I have the > feeling I was not getting these before, I can't be sure. Don't pay attention to these messages. They mean not what you think. The first message about CustomKeycodes mean... A keyboard driver in xfree was designed for AT keyboard and so expects AT scan codes in input. Since some of 'software platforms' (Linux, *BSD) are ported to non-PC hardware platforms the keyboard on such computers can emit another values as scan codes. So 'CustomKeycode' option was added for deal with such non-PC keyboards. It has not any relations to keycode - keysym mapping. (Note it says 'custom _keycode_' but not custom keysyms or custom keymap.) > On the other hand, maybe this is the root of the problem. What does "legacy > driver" mean ? I am using XKB, otherwise setxkbmap would not work. (Right?) And about 'legacy driver'. In new xfree design each input device must be handled by special separate module loadable at Xserver start. The mouse driver is already built as loadable module but keyboard still handled by subroutines buit in X server core and (inheritance from 'old xfree design'). So this message means that keyboard driver still buit in server core. Nothing more. > Does this mean that the customisations will not be implemented across all of > the XKB protocol ? Whatever this might mean. (Perhaps there will be > applications that recognise some of the customisations (xmodmap - key codes > and not key types), whilst other applications will recognise other > customisations or even none. Not at all. Ordinar keyboard input processing is hidden in Xlib. Since most of applications don't do anything except getting key events and their translation to keysyms (by X*LookupString) such applications know nothing about what protocol and what kind of keymap is used - 'core' or XKB. The xmodmap is exception. > Or is xmodmap just buggy ? And that is why it recognises the custom range of > keycodes, but not the custom key types, and then will not see the dynamic > change in the range of keycodes, but suddenly see key definitions that make > use of the default "THREE_LEVEL" type that wasn't previously defined. Note that xmodmap uses 'core protocol' for interaction with Xserver. The XKB server module tries to emulate 'core protocol' requests/replays for application that require it. But such emulation can't reflect all details of XKB keymap. So it is not strange that xmodmap shows not the same that xkbcomp can show. If you could send me your keymap I would can say more about this 'strange behavior'. (Maybe xmodmap or 'core protocol emulation' in XKB is really buggy.) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Why "Keyboard: CustomKeycode disabled" ???
> By the way, I have a couple of questions on this issue :
>
> - how do you set a key to directly go to a given group ?? I have set
> the shift keys to do previous/next group, but how do you say : go to
> group 1, go to group 3, etc. ? (first and last is no problem, but
> those in between ?)
It is quite easy with XKB.
For group number switching the XKB uses 'actions'. Normally these
actions are bound to special keysyms like ISO_Next_Group, etc.
But you can specify 'actions' directly in the XKB symbols file.
For example
key <...> { [NoSymbol], actions[group..]= [ LockGroup(group=2)] };
Or you can redefine some of unused ISO_* keysyms in appropriate
xkb/compat/* file.
For example
interpret ISO_Group_Lock {
action= LockGroup(group=2);
};
And if you don't like to change 'standard' keysyms you can invent own ones
using X11R6/lib/X11/XKeysymDB. (And of course add their interpretation to
your xkb_compat file).
> - xemacs complains about "iso-level3-shift" being not defined... I can
> still use the keys (like {, }, @, ... used a lot in perl !!), but it
> exits the search function and bips a lot (which I have turned
> off...). Do someone knows how to make Xemacs recognise the new
> XFree86 keys or at least keep silent ?
I'm not specilalist on emacs but I think you simply have to define it
but make it do nothing.
I met in news something like this
(define-key global-map [(iso-next-group)] "")
or
(define-key global-map 'iso-next-group (lambda () (interactive)))
Maybe your config already has such kind of define for iso-next-group.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]]xkb Turkish Unicode Symbol Problems
> Also, as Turkish language has a different capitalization rule for idotless and i, > the capslock key works weirdly. > > When the CAPSLOCK key is ON: > > Capital letter for idotless should be latin I but you got an idotless > Capital letter for latin i should be Iabovedot but you got a latin I > > (I reached a discussion about this capitalization rules in the mailing list > some time ago and the hack there worked-out for my old symbol file. > But for this new symbol file that hack simply does not work). It is strange. As far as I understand you have changed some key definition but didn't touch keys with i/idotless/I/Iabovedot. What else is different in your new symbols file (or your full coniguration)? And please remind me how this 'hack' finally looks like. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Why "Keyboard: CustomKeycode disabled" ???
> It is good to have this clearly explained! > > One thing that is buggy for sure is my own keymap, so I'll try to make it > work (I might accept your offer if I run into a dead end, because for now all > I can do is use altavista to get a bad translation of your XKB web pages.) I would like to offer my own translation but it is still incomplete (and English language is not my strong skill). Anyway, look at http://www.tsu.ru/~pascal/en/xkb/ > Therefore, my tests seem to show that the dynamic update of the valid range > of keycodes is only seen by xkbcomp not xmodmap. If this is a bug in xmodmap > itself or in XKB "core protocol emulation", I don't know. One would think > that, since xmodmap is not running all the time and should simply read the > valid keycode range from XKB "core protocol emulation", which running all the > time, xmodmap cannot remember the range of keycodes and so this is XKB's > fault. Yes. It seems that it's really bug in XKB server part. For our case a "core protocol emulation" means that Xserver keeps two instance of keymap. One map has XKB format and can be requested by xkbcomp and the second map has 'core protocol' format and it is the map that xmodmap can get. Thus for 'emulation' XKB has to make corresponded changes in 'core map' every time when xkb map is changed. But for some reason XKB don't resize the core map when xkb map is changed by xkbcomp request. It's funny but it do resize if new map is loaded by Xserver itself. Thus if one use setxkbmap (that doesn't send new symbols map to server but sends files names only and offer server to load new map from these files) he will not have such problem. (The fix is very simple - in one call a 'false' value must be changed to 'true'. But I don't know is it really occasional typo or resizing in this place can cause new problem). > Nevertheless, this is a minor and specific thing and should not > present any real problems. It can cause problem whan - at server start map with short range of keycodes was loaded - then needed map had been loaded by xkbcomp from some startup script - and then user will try to change some key out of keycode range by xmodmap. Of course, this case is rare but possible one. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]A keyboard with non-latin first group?
> I use the Bulgarian keyboard (first group for Latin letters and second > group for Cyrillic letters). When the first group is active > everything works fine. However when the Cyrillic letters are active > the modifier Alt doesn't work: when I press Alt+I the programs "think" > I've pressed Alt+Cyrillic_I. This is rather boring (and I hope > someday this will be fixed), but I can understand this. What I don't > understand is why the Control modifier works (well not everywhere) > when the keyboard is in Cyrillic mode. Why do programs react as if > I've pressed Control+I when I actually press Control+Cyrillic_I? Does > the Control modifier activates temporary the first group? You are right absolutely. The XLookupString() tries to make control code using keysym from current group but if it fails this subroutine "activates temporary the first group" and tries to make controlized code useing corresponded keysym from the first group. This behavior can be changed by _XKB_CONTROL_FALLBACK environment variable. (You guess it switched on by default.) > If it does, then the first group has to be filled with Latin letters. Of course, if you want such behavior. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]libc setlocale() and XSupportsLocale()
> Can anyone please give advice with the following problem: > > I installed XFree86 4.1.0 on my Linux/X86 system. Since I am using > glibc-2.2.4, for which locale support is good, I decided to build without X > locale support (X_LOCALE undefined during compilation). My system is > configured to support three locales in addition to the standard ones built > into libc, namely de_DE.ISO-8859-1, de_DE.ISO-8859-15 and de_DE.UTF-8. All of > those are accepted by setlocale(), but for de_DE.ISO-8859-15 > XSupportsLocale() returns FALSE. I assumed that if I did not define X_LOCALE, > then X would completly rely on the underlying system's locale handling and > not do any locale interpretation of its own, but that does not appear to be > the case? You are right regarding X_LOCALE. You really need not this option. But Xlib anyway uses own files that describes locale as addition to 'system locale' data. And Xlib need to find an appropriate locale file that match the system locale. To map system locale names to names of Xlib's locale files it uses locale.dir and locale.alias files in X11R6/lib/X11/locale. And you have problem becouse in these files there is not mapping for 'de_DE.ISO-8859-15' name. You need to add a string like de_DE.ISO-8859-15:de_DE.ISO8859-15 to the locale.alias file and a string like iso8859-15/XLC_LOCALE:de_DE.ISO8859-15 to the locale.dir (of course, if such string is absent) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]A keyboard with non-latin first group?
> > > If it does, then the first group has to be filled with Latin letters. > > Of course, if you want such behavior. > > Thanks. > > Is it possible to attach two actions to a key? No, it's impossible. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]The xkb with complex letter question again
Owen Taylor wrote:
> The standard input method system that comes with XFree86 is XIM; if you are
> using a language like Japanese, you'd have a standalone input method
> process; for simpler languages, there is a simple input method built
> into Xlib for doing composition. This is what the files referenced
> in:
>
> /usr/X11R6/lib/X11/compose.dir
>
> I believe (but am not sure) that you should be able to add an entry
> like:
>
> : "[lam][alpha]"
>
> into one of these files and have it work.
You are right absolutely. It must work.
I am surprised why nobody still mention it.
A Compose file usually used for combining a locale charset symbol from a
sequence of keysyms. But it seems nobody remeber that the result string
can be as long as you need. ( Actually it limited about 128 codes, but
it is 'plenty of space'.)
> But applications and toolkits may have other ways of doing things;
> GTK+-2.0, for instance, has it's own input method system that can be
> used either by itself or on top of input methods like XIM.
All applications which use X{mb|wc|utf8}LookupString or toolkits that
rely on their output should work correctly.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]combining xkb 'layouts'
Tzafrir Cohen wrote: > Hi all > > Short summary: I see a problem with combining several layouts in the way > "encouraged by XKB. An example to that problem is the question: how do I > create a layout of "English(US)+Romanian+Hungarian" I have almost completed new framework for XKB layouts and thought of writing rationale. But you have done this part. Thank you. I have a lot of help requests from people who want layouts with three alphabets or two ones but with non-US first part (English+Russian+Ukraininan, German+Russian, Great Britan+Russian, etc.) What I have done. First part is patches for a xkbcomp to make it recognize 'an explicit group specifying'. The modified xkbcomp understands as xkb_simbols strings like "first_map+second_map:2+third_map:3". There a colon with digit means that key definitions from the specified map should be shifted to group specified by digit. Of course, maps there must be keymaps where only one (first) group described. It allows use the xkbcomp itself for making keymaps instead of using editors or scripts. Note that these changes don't break compatibility with existent scheme becouse without the 'explicit group specifying' new xkbcomp works like present one. As the second part we need provide an adequate representation in rule/model/layout terms. But keeping compatibility here is more difficult. On the one hand we need a posibility to specify some layouts for one 'multilayout' xkb_symbols map. But on the other hand I would not like to change the API for a xkblib (which performs conversion from model/layout/etc. names to 'xkb components' names). And (maybe more important) until we make all existent 'layout files' suitable for using them as parts of multilayout map (maybe never), the xkblib has to distinguish a 'single layout' specification and specifying layout as part of the multilayout. So my changes for a 'xkb rule parser' are ... The XkbLayout can be 'comma separated list' of single layout names, for example XkbLayout "us,ru,ua" (if the list contains names more than 4 all names above this limit will be simply discarded). Inside the parser such list is splitted to single names which can be reffered in the rules file as layout[1], layout[2], etc. For example ! model layout[1] = symbols pc101 * = base(%m)+%l[1] ! layout[2] = symbols * = +%l[2]:2 Note that layout parts are numbered from 1. Internaly the layout[0] means 'traditional single layout' and also in XKB terms all groups have numbers from 1. The compatibility doesn't broken. If the layout name doesn't contain commas old rules with the 'layout' word will be applied only. Otherwise (comma separated list) only rules with 'indexed words' (like layout[1]) are used. There is issue of XkbVariant usage. This name is optional (so can be omited) and in traditional scheme with only one layout there can be only one xkbvariant. But since we use some layouts we need some variants were not all layouts need variants be specified. So in case where only last layout needs modification we can specify XkbVariants as ",,,nodeadkeys" for example. (Of course, I have added to rules 'indexed variants' too). But it looks ugly. Fortunatly, variants can be specified directly as part of the layout name - "us, ru(phonetic), ua(winkeys)". And the third part of work - we need rewrite all layouts map to make them 'single group' symbols maps. I have made few for testing but I don't dare to offer changes for all existent maps. Now I'm making last small fixes and I hope I will be able to offer my work in nearest days. (The last problem I have met is that a Xserver think itself smarter than the xkbcomp and carefully filters out all simbols in xkb_symbols name which, the Xserver supposes, can confuse the xkbcomp. So my non-standard symbol 'colon' became a victim of this filtering). > Suppose I want to have a "English(US)-Romanian-Hungarian" layout. > How do I map this into groups? > > (Note: I don't know European layouts too well. What I mean is two layouts > that each of which is currently mapped into two groups) Don't forget that the key in each group can have more than two 'shift levels' (up to 64 !). Currently most of maps (except Bulgarian and Czech) use only two levels in each group. But we can place keysyms that now occupate an additional group to an additional levels, and assign to AltGr key an additional modifier (for a third/fourth level shift) instead of 'group shift' action. (I guess that 'two levels in two groups' provides better compatibility for non-Xkb-aware applications. But one who really need multilayout map can use xkb-aware applications only and, of course, will never switch off the XKB support.) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROT
Re: [I18n]/etc/X11/xkb/symbols/bg
> Hi > now Mandrake have tool which can change keyboard from us to bg(phonetic) > and so on. Kxkb use /etc/X11/xkb/ to compile own db with languages. > And so on and so on. But Kxkb can't use definitions like bg(phonetic) > it change ones to correct type, and next time used first difinitions in > language file, for exsample /etc/X11/xkb/symbols/bg. > Anton Zinoviev tells me that Kxkb is wrong. Interesting point of view. Since one of keyboard swithcers in one of toolkits can't deal correctly with multiply variants in the single keyboard map you suggest to split all maps (sorry, not all but your favourite one only) to many separate files. > ALL other files for different languages have only one difinition and all > of them are defined like "basic"(there are 4 for US - us*). You are wrong. At least Russian an Ukrainian maps have 'basic', 'phonetic' and 'winkeys' variants. And almost all latin-based alphabet maps have 'nodeadkeys' varaint besides basic one. Do you think all of them need be splitted too? (instead of fixing Kxkb program). > I can't find who to ask at kde.org > and so on... AFAIK the Kxkb is actively developed now by Andriy Rysin <[EMAIL PROTECTED]>. Try to write him. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]combining xkb 'layouts'
Tzafrir Cohen wrote:
> While on that:
>
> Currently symbols files also map some modifiers. e.g, from symbols/ru
>
> modifier_map Shift { Shift_L };
> modifier_map Lock { Caps_Lock, ISO_Lock };
> modifier_map Control{ Control_L };
> modifier_map Mod3 { Mode_switch };
>
> Are all of them correct? I tend to think that there's too much copy&paste
> between the different symbols files.
I don't think they are incorrect but most of them are redundant.
I suppose there should be one a 'base' map with alphabet-independed keysyms
(modifier keys, function keys, keypad, etc.) which variant depends on
model (pc101, pc104, etc.). And most of modifier_map instructions can be
placed there. Some portion of modifier_maps can be in files added by
XkbOptions. It seems to me modifier_maps should never appear in
'partial layout' files.
> > Don't forget that the key in each group can have more than two
> > 'shift levels' (up to 64 !). Currently most of maps (except Bulgarian and
> > Czech) use only two levels in each group. But we can place keysyms that
> > now occupate an additional group to an additional levels, and assign
> > to AltGr key an additional modifier (for a third/fourth level shift) instead
> > of 'group shift' action.
>
> OK. So is there a problem?
There is not.
Just a lot of work for editing lot of files. :-)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]combining xkb 'layouts'
Pablo Saratxaga wrote: > The problem with that is it breaks compatibility for all non-latin > keyboards where two groups are used. > Imagine some people has defined his keyboard just as "ru" or "th" etc. > then he updates XFree86 and those files include only one group --> he > is unable to type any ascii and can't manage his system anymore... Sorry, I forgot to mention ... I don't intend to _replace_ existent layout maps by new ones. I know that all non-latin layouts are really two-layout maps where the first layout is 'US qwerty'. And we have to keep all of them at least some time. For new maps I'd suggest to use a special name extension (for example, .sg - 'single group') or place them in new subdirectory (for example, symbols/layouts). As I said in previous message, a new 'rules parser' distinguish the 'old style' layout specifying (one layout name only) and new one where more than one layout specified. And it use different rules for these cases. So it is not problem to use in rules different names or places for new 'single group' maps and for existent ones. > However, often the first group in such cases is always US qwerty. > So, what about making those files have an empty first group (that has already > been done for various keyboard files, it would just need to be done for > the remaining ones) and then have arule to xkb_simbols that says something > like: I would not like to make such kind of changes in xkbcomp. It is just a compiler. I would not like it have too much intellect to make assumptions what user meant omiting some part of map. But I hope we can provide all needed functionality using carefully designed rules. > I was thinking about the "phonetic" layouts, their purpose is to allow > to type a non latin script with a latin keyboard that doesn't have the > non latin letters printed on the keys. > They are based on an US qwerty keyboard. Yes. I thought about differences of latin-based keyboards and problems it can cause for any secondary layouts. > For example in a cyrillic phonetic layout the letter with keysyms 'a' > should sent the cyrillic a, and not the key . on an US keyboard > key has the keysym "a", but not on a French keyboard. > > Would it be possible to have keyboard groups defined not > by keyboard layouts (key -> keysms) but by keysym aliasing (keysym -> keysym) > things like: > > a = Cyrillic_a > A = Cyrillic_A > b = Cyrillic_be > ... I don't know how to assign (in the XKB) a key description to keysym instead of keycode name. (The xmodmap has such posibility but it seems to me rather dangerous.) But the XKB has so called 'keycode aliases' that can help, I suppose. We can compose special xkb_keycodes files with such aliases ( with "alias = " for 'us' keyboard and "alias = for French one). And add them by rules like ! layout[1] = keycodes us = +aliases(us) fr = +aliases(fr) ... ( By the way, a present rules parser allow to add some partial files in 'options' rules only. I consider this restriction as too strong and unnecessary. So I have added in modified parser a posibility to use additions (rules where a right side expression begins from '+' or '|') in any rules. But we need to be careful with a rules order.) There still is issue that 'alias originating layouts' must be specified as first ones. But the same problem we would get using keysym_to_keysym assignments. There is another approach - to use 'extended names' of model (pc102_qwerty, pc104_qwertz, etc.) for aliases choosing. And finally we can combine both approaches. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]combining xkb 'layouts'
Pablo Saratxaga wrote: > That would also avoid the need for a lot of variants, eg instead of > > "us(euro105)" it will be "us+euro105" (the difference between "us(default)" > and "us(euro105)" is mainly the interpretation of the meaning of right Alt > key and the extra "windows" keys etc. something that isn't related to US > layout in any way. > And then the same "euro105" could be used for other layouts, eg: > "fr+euro105", "be+euro105" etc. > > What do you think about it? I agree. I is nonsense that 'us' keyboard has 'euro' variants. All variants of Multi_key and Mode_switch placement can be put into options (maybe axcept one varinat placed directly in national layout as defaults). I suppose the existent scheme with many variants and includes is too complicated. And writing new files set we have a good chance to rewrite them from scratch making them as simple as posible. (Then we will have plenty of time to make them as complicated as they are now :-). -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]combining xkb 'layouts'
Pablo Saratxaga wrote: > > I know that all non-latin layouts are really two-layout maps where the first > > layout is 'US qwerty'. And we have to keep all of them at least some time. > > For new maps I'd suggest to use a special name extension (for example, > > .sg - 'single group') or place them in new subdirectory (for example, > > symbols/layouts). > > But that means duplicating half of the files; it's a real waste. I meant those files will coexist only while time for migration from a present layout model to new one. In MS Windows when I choose 'Russian keyboard' I get the russian keyboard map only without any latin ones. And non-latin writing Windows user know they need to choose 'en' keyboard explicitly (as primary or secondary one) if they want it. The same can be done with 'XKB multi_layout model'. All non-latin writing users should specify 'us,ru' (or 'en,ru') layouts when they need it. But if you suppose it too difficult for Unix users ... OK. For case where only one (non-latin) layout name is specified we can write rules like ! model layout = symbols ... ru = base+us.sg+ru.sg:2 and avoid duplication. > Better would be to have a special keyword or something so the files > can remain single group, but be identified as non-latin; and if such > a file is loaded alone, then silently add "us" layout in group 1 and switch > the asked file to group 2. I can't imagine where this 'special keyword' can be placed and checked but at least we can mention all such layouts in rules ... ar = base+us.sg+%l.sg:2 ... il = base+us.sg+%l.sg:2 ... ru = base+us.sg+%l.sg:2 etc. I suppose it is not too bad. > > I don't know how to assign (in the XKB) a key description to keysym > > instead of keycode name. (The xmodmap has such posibility but it seems to me > > rather dangerous.) > > It should be allowed only for group 2 and up, not for the first one. > So there will always be a clean layout. Indeed. > > But the XKB has so called 'keycode aliases' that can help, I suppose. > > We can compose special xkb_keycodes files with such aliases ( with > > "alias = " for 'us' keyboard and "alias = > > It would be better to implement a new and specific support for real > keysyms aliases (if the idea seems ok, if not, it is not that important). It could be better but need deep changes for xkb files parser. Therefore let stay on my solution with keycode aliases. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Combining xkb layouts.
Hi,
I'd like to offeer my solution for 'multi layout' xkb maps.
I remind it allow to specify XkbLayout (and XkbVarinat) as list
of layout names that will be combined in one 'multi_layout'.
You can use use such list in XF86Config file
Option "XkbLayout" "us,il,ar"
or as an argument of the setxkbmap program
setxkbmap -layout "us,il,ar"
There are two files attached. The first one is a patch for all files
that need be changed. I remind the patch doesn't break compatibility
and existent rules and layout maps can be used.
The second file is example only of a new rules file and new 'single group'
xkb_symbols files. It contains a few such maps for non-latin (il, ru, ua)
and latin-based (us, de, fr) keyboards. All them are placed in separate
subdirectory (xkb/symbols/pc) and should not override existent maps.
But the rules file 'xfree86' is replacement for existent one.
I also have made a ru_phonetic map (it should be part of the 'ru' map)
which use 'keycode aliases'. You can see that it produces different maps
being used above us, de or fr layouts.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
--- xc/lib/xkbfile/maprules.c.orig Tue Feb 26 02:36:22 2002
+++ xc/lib/xkbfile/maprules.c Tue Feb 26 18:32:58 2002
@@ -67,11 +67,13 @@
#endif
#ifdef DEBUG
-#define PR_DEBUG(s)fprintf(stderr,s)
-#define PR_DEBUG1(s,a) fprintf(stderr,s,a)
+#define PR_DEBUG(s)fprintf(stderr,s)
+#define PR_DEBUG1(s,a) fprintf(stderr,s,a)
+#define PR_DEBUG2(s,a,b) fprintf(stderr,s,a,b)
#else
#define PR_DEBUG(s)
#define PR_DEBUG1(s,a)
+#define PR_DEBUG2(s,a,b)
#endif
/******/
@@ -252,8 +254,12 @@
};
typedefstruct _RemapSpec {
+ int number;
int num_remap;
- int remap[MAX_WORDS];
+ struct {
+ int word;
+ int index;
+} remap[MAX_WORDS];
} RemapSpec;
typedef struct _FileSpec {
@@ -261,8 +267,49 @@
struct _FileSpec * pending;
} FileSpec;
+typedef struct {
+ char * model;
+ char * layout[XkbNumKbdGroups+1];
+ char * variant[XkbNumKbdGroups+1];
+ char * options;
+} XkbRF_MultiDefsRec, *XkbRF_MultiDefsPtr;
+
+#define NDX_BUFF_SIZE 4
+
/******/
+static char*
+#if NeedFunctionPrototypes
+get_index(char *str, int *ndx)
+#else
+get_index(str, ndx)
+ char*str;
+ int *ndx;
+#endif
+{
+ char ndx_buf[NDX_BUFF_SIZE];
+ char *end;
+
+ if (*str != '[') {
+ *ndx = 0;
+ return str;
+ }
+ str++;
+ end = strchr(str, ']');
+ if (end == NULL) {
+ *ndx = -1;
+ return str - 1;
+ }
+ if ( (end - str) >= NDX_BUFF_SIZE) {
+ *ndx = -1;
+ return end + 1;
+ }
+ strncpy(ndx_buf, str, end - str);
+ ndx_buf[end - str] = '\0';
+ *ndx = atoi(ndx_buf);
+ return end + 1;
+}
+
static void
#if NeedFunctionPrototypes
SetUpRemap(InputLine *line,RemapSpec *remap)
@@ -273,16 +320,20 @@
#endif
{
char * tok,*str;
-unsigned present;
+unsigned present, l_ndx_present, v_ndx_present;
register int i;
+intlen, ndx;
+_Xstrtokparams strtok_buf;
#ifdef DEBUG
Bool found;
#endif
-_Xstrtokparams strtok_buf;
- present= 0;
+
+ l_ndx_present = v_ndx_present = present= 0;
str= &line->line[1];
+ len = remap->number;
bzero((char *)remap,sizeof(RemapSpec));
+ remap->number = len;
while ((tok=_XStrtok(str," ",strtok_buf))!=NULL) {
#ifdef DEBUG
found= False;
@@ -291,17 +342,40 @@
if (strcmp(tok,"=")==0)
continue;
for (i=0;i len) {
+ char *end = get_index(tok+len, &ndx);
+ if ((i != LAYOUT && i != VARIANT) ||
+ *end != '\0' || ndx == -1)
+ break;
+if (ndx < 1 || ndx > XkbNumKbdGroups) {
+ PR_DEBUG2("Illegal %s index: %d\n", cname[i], ndx);
+ PR_DEBUG1("Index must be in range 1..%d\n",
+ XkbNumKbdGroups);
+ break;
+}
+} else {
+ ndx = 0;
+}
#ifdef DEBUG
found= True;
#endif
if (present&(1num_remap++]= i;
+ present |= (1num_remap].word= i;
+ remap->remap[remap->num_remap++].index= ndx;
break;
}
}
@@ -314,8 +388,8 @@
if ((present&PART_MASK)==0) {
#ifdef DEBUG
unsigned mask= PART_MASK;
- fprintf(stderr,"Mapping needs at o
[I18n]An XKB layouts (variants, models, etc.) description.
Hi,
I'd like to talk about one XKB issue.
I have correspondence with two guys who write and maintain GUI applications
for the XKB based keyboard layouts switching and configuring.
Such applications need a complete list of all possible names of the XKB
models, layouts, variants and options (or better - their descriptions).
Of course, there is such list in a xkb/rules/xfree86.lst file (or in
similar files). And even there is one undocumented function in an xkbfile
library that deals with this file and returns names and descriptions as
simple arrays of string.
But this simple API needs some improvements and moreover the *.lst file
format needs some changes.
First of all the file contains (and the function returns) the variants
description list as a one global section. Actually it is almost empty and
the reason is clear. The 'variant' here means 'the variant of a particular
layout map' and a variants list can differ (and really is different) for
different layouts. Thus the variants list should be a subsection of each
layout description or each variant description in the global list should
have an attribute which points to the layout where this variant actually
makes sense.
Also the options list actually is not a plain list. It contains particular
options descriptions and common descriptions for 'groups of options' mixed.
Since the API function returns all those descriptions as plain list each
application needs do some additional parsing for such list.
Since the API and the *.lst file need be changed we decided don't invent
own format but use an XML for the description file. (A DTD draft attached.)
Note that such changes don't touch other parts of XFree becouse it seems
no one application from XFree distributive uses that file. (Actually there
is at least one which uses, it's a xf86config. But for the first time an 'old
style' *.lst files can be generated automaticaly from *.xml files at
installation time.) Thus what we need now is keeping this file up to date
only.
But there are some issues which we still have not agreement for.
First of all we would like to have descriptions translated to other
languages (as many as possible). An existent *.lst files scheme implies that
translated descriptions are placed in separate files for each language.
Should we use the same approach for new files or keep all descriptions in
one file? (A proposed DTD implies the last approach.)
The next one, althought the variants lists are subsections of layout
elements there are some variants that are repeated in many layouts
('nodeadkeys' or 'phonetic' for example). Would it better to keep descriptions
themself in the global section and use references to them in layout elements
or put similar descriptions into each layout variants subsection?
And finally, what place is better for the *.xml and *.dtd files?
Now I intend to put them into xkb/rules directory. But maybe someone know
the better place?
Any comments?
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
Re: Can this be added to the X distrib? Re: [I18n]Fwd: The Turkish language support
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 { 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
Re: [I18n]en_US.utf8/XLC_LOCALE bogus?
Owen Taylor wrote: > I'm certainly not certain that we shouldn't set up the font sets that > way, but some reasons I didn't suggest it were: > > - There are some strange effects that occur for the user if you >list all the font encodings individually with iso10646-1 last. > >An important one is, if I have, as my fontset specification: > > -*-arial-medium-r-normal--*-140-*-*-p-*-*-*, > -*-helvetica-medium-r-normal--*-140-*-*-p-*-*-* > >And (for the sake of discussion) say that I have arial in only >iso10646-1, but I have helvetica in both iso10646-1 and >iso8859-1. Then I'll get Helvetica for iso8859-1 characters, >not Arial. Nothing strange. A fontset creation procedure applies a basename list to each charset separately and chooses the first matching font, i.e. the font with the first basename from the list for which a matched font exists. Thus in your example the creation procedure skips an arial for the iso8859-1 encoding and chooses a Helvetica font for it but for the iso10646-1 encoding the procedure can find the arial font and shooses it for the iso10646-1. On the other hand if your encoding list contains the iso8859-1 encoding before the iso10646-1 a DrawString procedure tries convert the string to the iso8859-1 (and draw it with chosen font) and only if this attempt fails it tries other encodings. > - I've had performance problems with putting long lists of fonts >into XLC_LOCALE, especially if the lists of fonts includes CJK fonts. >It's possible that there is something broken with the on-demand >loading implementation in the XFree86 Xlib. I think the Xlib itself is not broken. The thing is the on-demand loading means that the creation procedure uses the XListFontsWithInfo call instead of the XLoadFont. But the XListFontsWithInfo needs to open and read the font file (unlike the XListFont which need not) and it cause the dealy you see. It seems this 'font info' isn't used by the Xlib itself but can be requested by an application using the XFontsOfFontSet call. > - It's not clear to me where you should stop in listing character >sets if you list individual character sets. XFree86 has 38 >different font encodings listed in xc/fonts/encodings. > >Even if on-demand loading is working, there are going to be >performance for having too big a list of character sets in >the XLC_LOCALE. It means we shouldn't use one XLC_LOCALE for all *.UTF-8 locales but a separate XLC_LOCALE file for each one with a small list of 'native' encodings and the iso10646-1 as the fallback. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]An XKB layouts (variants, models, etc.) description.
Hi, > I had no time to do but I think it should be somehow compatible with > a new .sg and layer design. I'm looking forward to summer when I will more > likely have the time. Could you pass me over the contact to those GUI guys? OK. There is a mail list where they (and me too) discuss related issues. Since there were not non-Russian speaking people there we wrote all messages in Russian. It doesn't mean you can't write English there but we can't offer you to read its archive, sorry. The list address is [EMAIL PROTECTED] You also can write directly to Sergey V. Udaltsov ([EMAIL PROTECTED]) who is an originator of the list and its most active member. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
