Re: [I18n] urdu keymap
Hi Zaeem, Today at 18:32, Zaeem Arshad wrote: i have developed an urdu keymap for XFree86 that enabled typing in urdu. We have been actively testing it for 4 months and using it for localizing GPL/OSS projects. Kindly tell me how can this keymap be submitted to the main X release so that it can be included in further releases. I will be much grateful. This is the place to send it, but I believe it's better to put it in Bugzilla: http://bugzilla.xfree86.org (so it won't be forgotten). You may also wish to get in touch with xkb-config project at [EMAIL PROTECTED] (it's part of FreeDesktop.org project), but I suspect it's not necessary since Ivan is a member of both ;-) Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Emulation of Alt+Numpad+Digits behavior
Yesterday at 19:35, Jrg Henne wrote: Markus Kuhn wrote: If you do something in this area, please implement the ISO 14755 hex input method, and not the old MS-Windows one. (Or implement both together, if you really need MS-Windows compatibility here. They don't interfere with each other, because the ISO 14755 technique uses Ctrl-Shift to activate the hex-entry mode, while MS-Windows uses Alt.) For reasons stated in my previous message I really need the DOS/MS-Windows method. However, if there is a viable solution for either of the methods, implementing at least the sections 5.1 and 5.2 (basic and keyboard symbol entry) from ISO 14755 should be fairly straight-forward. Therefore I'll consider implementing both of them, but first I need a viable solution anyway. Gtk+ 2 already implements Ctrl-Shift stuff. Just try it in any GtkTextEntry. Cheers, Danilo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [I18n] Re: Emulation of Alt+Numpad+Digits behavior
Yesterday at 19:35, Jrg Henne wrote: Markus Kuhn wrote: If you do something in this area, please implement the ISO 14755 hex input method, and not the old MS-Windows one. (Or implement both together, if you really need MS-Windows compatibility here. They don't interfere with each other, because the ISO 14755 technique uses Ctrl-Shift to activate the hex-entry mode, while MS-Windows uses Alt.) For reasons stated in my previous message I really need the DOS/MS-Windows method. However, if there is a viable solution for either of the methods, implementing at least the sections 5.1 and 5.2 (basic and keyboard symbol entry) from ISO 14755 should be fairly straight-forward. Therefore I'll consider implementing both of them, but first I need a viable solution anyway. Gtk+ 2 already implements Ctrl-Shift stuff. Just try it in any GtkTextEntry. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Switching directly through multiple keyboards
Hi Ivan, On Saturday at 13:07, Ivan Pascal wrote: To express it more factually, is there a way to assign, let's say SHIFT+SHIFT to a greek polytonic kbd, SHIFT+ALT to sanscrit, SHIFT+META to phonetics, etc. Look inside keysymdef.h for possible symbol names which might produce desired behavior. You can notice that it's possible to switch directly to either first or last group, but not to a specific number. But note that the meaning of those keysyms is not hardcoded somewhere. There are 'interpret' records (in xkb/compat/* files) where those keysyms are tied with 'xkb actions'. But all possible actions are not limited with keysyms mentioned in the interpret records. [snip] Thanks, it's nice to always gain new insights through your mails. It seems XKB mechanism is very much complicated, but you make it sound much less so. It's great to learn new stuff, so I thank you for being so responsive and willing to share the knowledge. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Switching directly through multiple keyboards
Yesterday at 22:09, Vincent wrote: Hello ! A friend of mine, quite involved in ancient greek, sanscrit and phonetic alphabet has defined multiple xkb keyboards file. He wanted to know if there is a way to shift directly to a particular definition, rather than cycling through 3 or 4 different ones. To express it more factually, is there a way to assign, let's say SHIFT+SHIFT to a greek polytonic kbd, SHIFT+ALT to sanscrit, SHIFT+META to phonetics, etc. Look inside keysymdef.h for possible symbol names which might produce desired behavior. You can notice that it's possible to switch directly to either first or last group, but not to a specific number. #define XK_ISO_Group_Shift 0xFF7E /* Alias for mode_switch */ #define XK_ISO_Group_Latch 0xFE06 #define XK_ISO_Group_Lock 0xFE07 #define XK_ISO_Next_Group 0xFE08 #define XK_ISO_Next_Group_Lock 0xFE09 #define XK_ISO_Prev_Group 0xFE0A #define XK_ISO_Prev_Group_Lock 0xFE0B #define XK_ISO_First_Group 0xFE0C #define XK_ISO_First_Group_Lock 0xFE0D #define XK_ISO_Last_Group 0xFE0E #define XK_ISO_Last_Group_Lock 0xFE0F The usual group switching symbol is ISO_Next_Group above, but you may use any other as well (if you use shift_toggle from standard XKB options, you get ISO_Prev_Group as well). If this is not sufficient, other programs such as GSwitchIt (later versions integrated into Gnome 2.6) provide more options, and do exactly what you call for. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Alt + CHTN for arrow key movement, XKB?
Yesterday at 1:00, Ahmad Baitalmal wrote: - In Gnome (I'm running 2.6 on xfree-4.3.99.902-r2) hitting the c key by itself is somehow interpreted as ALT+C. So when I'm filling a text box in a dialog box, when I hit c the dialog box calls up the Cancel button since it has C underlined. The same for T , H, and N. If there is a toolbar accelerator for them, ther are called just by pressing the key. Not sure if there is something I can do here could be a gnome issue? This is a Gtk+ issue. Try looking at http://bugzilla.gnome.org/show_bug.cgi?id=100439 I don't think there's yet a proper solution. If you've got time to look into it, I'd be interested as well. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Alt + CHTN for arrow key movement, XKB?
Hi Ahmad, Yesterday at 22:09, Ahmad Baitalmal wrote: SO the solution for me was to patch gtkkeyhash.c and force it to set the correct consumed_modifiers when the keys I care about are pressed. Here is the patch file: http://ahmad.baitalmal.com/xkb/ gtk_altnav_consumed_modifiers_fix.patch I don't remember the details, but I believe I attached the patch there which basically inhibits some of Gtk+ functionality, yet makes some similar functionality to yours work. It was outright wrong, but it made it work for me (I was testing with advanced Serbian keymap from http://srpski.org/dunav/ which sends out English combinations when Ctrl+Cyrillic_letter is pressed; eg. if you press Ctrl+Cyrillic_A, programs receive Ctrl+A; Gtk+ handles that by itself, so that causes the conflict; XFree86 4.4 also handles that by itself in a nicer way, so I didn't bother with it too much, and I use almost exclusively Gtk+ apps, so I don't notice the lack of functionality elsewhere). Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Unicode keysym questions
Alexander Krauss [EMAIL PROTECTED] :
I also noticed that the Compose-Files of 4.3.0 in UTF-8 locales use the
U keysyms even for characters that have old keysyms (all the accented
latin-{12...} chars). Is this an intended policy change or did it just
happen because they were automatically generated? Note that for example
xemacs does not interpret these keysyms yet, which breaks the input of many
latin-1 chars on 4.3.0 with UTF8 locale.
Don't know about all the policy stuff you're wondering about, but at
least GNU Emacs from CVS handles these just fine.
Cheers,
Danilo
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] KeySyms 5 to 8, multiple character sequences
Hi Jacek, Jacek M. Holeczek [EMAIL PROTECTED] : Basically, I cannot see how can you have a portable one-definition-fits-all keymap if such things change (keycodes and layout of the keyboard). Have a look at this mail : http://www.mail-archive.com/[EMAIL PROTECTED]/msg01608.html Ivan U. Pascal explains there the new .XCompose and $XCOMPOSEFILE implemented in the 4.4.x : ^^^ This is what the problem is -- the initial request was because of having to switch between several X servers, with probably only a tiny portion of them being XFree86 servers, let alone XFree86 4.4 (CVS or prerelease). XFree86 4.3 also has some very interesting features not present on other X servers (like multi-layout combining) or earlier XFree86's, but in such cases it would be best to create standalone file from xkbcomp, and carry that with you and use it wherever is the XKB available. Simply, xkbcomp provided with earlier XFree86's or other X servers is incapable of joining multiple layouts, but the resulting already-combined map can be used without any problems. The keycodes shouldn't differ much, but that means that you might have problems with eg. Lock and Control switching places, or similar. Still, regarding the circumstances, I'm still convinced that this is the best (partly) solution. Perhaps it's also possible to I've also tried this and removed the keycodes section from the generated file, and it seemed to work fine on XFree86 4.3 (please report how it works for other systems): (you do the following on the system with a sr map you'd like to use everywhere) $ setxkbmap sr -print | xkbcomp -o sr.xkb -xkb - (now you remove the xkb_keycodes section from generated sr.xkb and you carry sr.xkb to other systems, and do the following on other systems) $ xkbcomp -merge -synch -a sr.xkb :0.0 Of course, adjust setxkbmap command, and display (:0.0) part of xkbcomp command to suit your needs. This should make use of server provided definitions of keycodes (that's what -merge should do, though it worked for me even without that option on XFree86 4.3), and they're basically like coordinates: AE03 indicates fifth-row, third key (or was it zero-based and fourth key?). If all the other servers have this kind of mapping, this should probably work (but I'm just guessing, please test and report back). Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Compose and Gtk2/Mozilla
, 30. 2003. 17:58:33 CEST Owen Taylor : As far as I know, you shouldn't lose that. That's done completely separate from input method handling. Uhm, I must have been mistaken. I remember having problems with it a week or so ago (with Gtk+ 2.2.4), but I cannot replicate it now. It must have been some other thing, sorry for pointing in the wrong direction :-) The main thing you will lose Control-shift-hex-digits Unicode input. Wow, I didn't even know those existed -- thanks :-) A) Operating system independence - GTK+ needs to handle compose sequences when not running under X as well, making the operating system independent input method the default means it gets tested. B) Full set of Unicode compose sequences when not running under a Unicode locale Thanks for explaining those bits. C) Get to add some extra neat features like the control-shift digits support. Yes, I never knew about them -- I just love it ;-) For many scripts, Pango does that. Yes, I know that, and that's why I was surprised (if not disappointed) that it doesn't handle a really simple case like I'm about to describe. If you have a font/script combination that you wish that was handled, I can point out where in the code it would need to be handled. Making Unicode normaliation forms NFC and NFD render the same always is suprisingly tricky, but specific instances are not hard to handle. Okay, the problem is really simple. Serbian language uses a cyrillic alphabet, and four diacritics/accents. In normal texts (meaning, not a linguistic or grammar-related text), accents are not normally used except in a few cases where they're used to distinguish words otherwise the same (like kod meaning at and kd which came from code, with long o, or da meaning to, or d meaning give -- seen very frequently in constructs like he wants to give). What's worse is that many Serbians are so far using latin a-circumflex or o-circumflex because their glyphs are the same as those for cyrillic a and o. This four accents are used only at vowels (in Serbian, those are a, e, i, o and u, cyrillic of course). Unfortunately, Unicode is not planning to insert these characters precombined (even after several requests), probably basing their reasoning that all Unicode-aware tools support decomposition and composition, or perhaps because of their supposed goal of coding just characters, not their variations (which was unachievable from start, because for they've included fi, fl and other ligatures for various compatibility reasons). So, I'd gladly appreciate the pointer to where should I look for implementing these kind of mappings (four accents over any of five letters). Ok, I've checked out Pango sources and will delve into them later, but I'd still take any pointers you've got. Thanks again for sheding some light into these issues. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] why does Mode_switch not work sometimes?
2003.08.27 09:28 Frank Murphy : However, on this one machine Mode_switch doesn't have any effect, no matter what key i assign it to. Another thing you could try would be to set up an Esperanto XKB keymap based on whichever national keymap you're using, though the ideas behind Mode_switch and ISO_Level3_Shift have changed in XFree 4.3. If the problem is on the old XFree86, perhaps you could try using ISO_Next_Group instead of Mode_switch? Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XKB symbols normalization proposal
Okay, I'll mention some technical (and political) points that you missed. Frank Murphy wrote: ... National: ... sr (Serbia) sr is a country code for Suriname, so this one is linguistic, and should be renamed to scc (a long unchanged code originating from Serbo-Croatian in Cyrillic). There will be some nice *political* discussions relating to this change (eg. if Croatian map which would be related to Croatian *language* as used in eg. Bosnia and Herzegovina would have to be named scr from, I guess, Serbo-Croatian in Roman) ;-) I don't mind, but my guess is that there will be virtual breakages in policy -- one will make use of the fact that the country and language code are the same, and have a linguistic map behind the country code. In the linguistic keymaps, change existing files to their 639-2B code. ... - move the Greek keymap from 'el' to 'gre' If I may know, how did you come to the conclusion that this is indeed a lingustic keymap? Based on the file name? I believe this one can also be put into national keymaps category, and perhaps a rename to the corresponding country code of Greece (gr) would also be needed (which is practicaly the same as your proposal). Of course, I may have missed something. All the other things seem to be well covered, though I'd check all the codes if they really align with the mentioned ISO standards (like you missed Serbian, maybe you missed another one). Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
, 14. 2003. 04:32:57 CEST Frank Murphy :
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
I'd go for:
key AE01 { [ 1, exclam, any, any ] };
(I'm not sure if your idea would work like this -- if it would,
then this is unneccessary burden).
(Btw, basic in pc/us is practically us, eg. just calling
setxkbmap -layout us will set the pc/us(basic) map).
Wouldn't `setxkbmap -layout us` set the us(basic) map and
`setxkbmap -layout pc/us` set the pc/us(basic) map?
AFAIK, not on the XFree86 4.3.0, eg.:
$ setxkbmap -layout us -print
xkb_keymap {
xkb_keycodes { include xfree86+aliases(qwerty) };
xkb_types { include complete };
xkb_compat{ include complete };
xkb_symbols { include pc/pc(pc105)+pc/us+group(shift_toggle)
};
xkb_geometry { include pc(pc105) };
};
Using a German keymap doesn't prohibit you from typing in English.
However, if you own a keyboard made for Switzerland, but you set
the keymap to be German (the dominant language here), you won't be
able to type the characters on your keyboard -- like finding
the @. Besides novices won't be setting this, the administrator will.
The thing I wanted to point out that if someone was offered with a
choice that read Germany (implying a country name) instead of
German,
it'll be easy to mistake it for enter your current location.
It's a sort of Great Britain for the english layout -- would you ever
look for that if you needed english layout?
OTOH, when it says German there are no doubts, even if you're right
now sitting in a hotel in Germany wishing to type in English ;-)
So, I cannot see any advantage to the naming scheme you seem to be
proposing, yet there are many disadvantages.
I agree. I think there are two ways of looking at this, but there are
three
types of keymap files: national (based on ISO 3166 country codes),
linguistic (ISO 639 language codes) , and random.
Looking just in the pc/ directory, I see the following breakdown:
National:
al (Albania) am (Armenia) be (Belgium) bg (Bulgaria) br (Brazil) by
(Belorussia) cz cz_qwerty (Czech Republic) de (Germany) dk (Denmark)
ee (Estonia) el (Greece) es (Spain) fi (Finland) fo (Faroe Islands) fr
fr-latin9 (France) gb (Britain) ge_la ge_ru (Georgia) hr (Croatia)
ie (Ireland) il il_phonetic (Israel) ir (Iran) is (Iceland) it (Italy)
lo (Laos) lt (Lithuania) lv (Latvia) mk (Macedonia) ml (Malaysia) mm
(Burma)
mt mt_us (Malta) nl (The Netherlands) no (Norway) pl pl2 (Poland) pt
(Portugal) ro (Romania) ru (Russia) se (Sweden) si (Slovenia) sk
sk_qwerty
(slovakia) sr (Serbia) th th_pat th_tis (Thailand) tj (Turkmenistan)
tr
(Turkish) ua (Ukraine) us (United States) uz (Uzbekistan) yu
(Yugoslavia)
Actually, many of these are the same for language and nation name,
thereby, this category would shrink very much. Besides, some would even
go to only lingustic (like sr for Serbian, because Serbia is a part
of
larger country Serbia and Montenegro with ISO 3166 codes of CS and
SCG).
The others, like de, es, fi, fr, hr, it, mk, nl, no,
pt,
ro, ru, sk, th, tr apply to *both* language and country
(actually,
these are the ones I know about; there are probably others).
Linguistic: ar(abic), ben(gali), hi(ndi), guj(arati), gur(mukhi),
iu(inuktitut), kan(nada), ogham, ori(ya), sami, telugu, tamil
Perhaps, if we'd add the ones above, this list would be much longer ;-)
Random: dvorak en_US la latin pc
So it seems that a good compromise would be to recomment the ones of
the national type to reflect the name of the country (in English), and
to leave the ones of the lingustic type to refect the name of the
language (in English). Does that address your concerns?
I see your point and it makes sense. Though, I'd go for an international
standard, because they've already invested time into avoiding
collisions.
For the sake of difference, I would recommend the following:
- National keymaps should use ISO 3166 code in all UPPERCASE (eg. US)
- Linguistic keymaps should use ISO 639 code in all lowercase (eg. en)
This would allow one to have de which could apply to all the
countries where German is used (eg. de(DE)) and also a DE which
would only apply to Germany. In your example, CA (if that's the code
for
Canada) would have CA(en), CA(fr), while fr would have fr(CA),
fr(FR),... It's up to the implementor to choose and see where to put
the actual definitions, and where to simply include them from the other.
Of course, this would cause *major* breakage for old applications which
rely on one layout being there with a specific name.
And just as a sidenote, this wouldn't prohibit any other variations. It
would just be unwise and unrecommended to use two-letter codes for
naming
xkb_symbols sections
Re: [I18n] Re: Some thoughts on XKB symbols
, 14. 2003. 13:12:05 Dr Andrew C Aitchison : On Thu, 14 Aug 2003, Danilo Segan wrote: For the sake of difference, I would recommend the following: - National keymaps should use ISO 3166 code in all UPPERCASE (eg. US) - Linguistic keymaps should use ISO 639 code in all lowercase (eg. en) Is this going to cause us to run into CVS problem we had resentily, where we couldn't rename file hp to directory HP (or similar) ? Very much probable -- I completely forgot about the insane operating systems that cannot differentiate between lower- and uppercase (you didn't raise this point, but I was reminded of it, and it seems valid), and about the CVS software limitations (regarding renames). Though, if anything of this scale is to be done, I'd be very eager to add a completely new directory (namespace) in order not to break compatibility. Eg. I'd introduce a new xkb/symbols/improved directory where to put these kind of maps ;-) When, and if most of the maps from symbols/pc and symbols/ directory have gotten their corresponding map in the symbols/improved would I go for making it the default. In your example, CA (if that's the code for Canada) would have CA(en), CA(fr), while fr would have fr(CA), fr(FR),... It's up to the implementor to choose and see where to put the actual definitions, and where to simply include them from the other. Is there a difference between CA(fr) and fr(CA)* Does the user care about it ? Should we make them mean the same thing? *FR(ca) would be different, although possibly unimportant or meaningless. I'll rephrase the above claim that it's up to the implementor to choose and see where to put the actual definitions, and where to simply include them from the other. That was meant to say that each can be defined separately (actual definitions), thus being different. Yet one may decide that they are the same, and simply use 'include fr(CA)' in the definition of CA (fr). I believe that all maps of this form should be the same, at least from a user's perspective. So, yes is the answer to your question -- they should be made the same. It's just about a preference one likes to use when *calling* the map (s)he needs. FR(ca) in that context would refer to France (country) and Catalan (I believe 'ca' is ISO 639 code for Catalan; sorry if I am wrong). If Catalan is not used in France, this would probably be undefined. Similarly, just using FR (implying FR(basic)) should make use of FR(fr) (because French is official language of France), and using fr would imply using fr(FR). All the other cases must be explicitely asked for. This would make a clear distinction between country standards, and language support (yet, keep their relation where such exists). Yes, implementors would have a bit greater task at their hands, but it seems beneficial. All of this can be remedied by keeping a database of mappings between languages and countries (eg. mapping fr(CA):CA(fr); en(CA):CA(en); de(CH):CH(de); ...). I admit that I have not researched this approach, and it came just as a wild idea on the issue that Frank raised. So, please express your concerns. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
, 13. 2003. 18:58:40 CEST Frank Murphy : The only xkb_symbols us that I see are in digital/us and xfree68/ataritt. But the map would be the same as the xkb_symbols basic in pc/us, basically, the same as latin(basic) only not including the group 2 or 3 symbols (exclamdown, etc.). However, it would be in the latin file and included in the other us files. Could you please differentiate between levels and groups in XKB terminology. All keymaps in pc/ should use *only* one group to facilitate multi-layout features of XKB in XFree 4.3. But basicaly, this could be done simply without breaking compatibility. You just create a xkb_symbols(ascii) in pc/us file, and put NoSymbol or any on higher levels, and just include that from basic. (Btw, basic in pc/us is practically us, eg. just calling setxkbmap -layout us will set the pc/us(basic) map). In this manner, all the keymaps which would need just the ASCII part, without other US parts, could include pc/us(ascii). OK, so we can pick another name. My point is to preserve the (blurred) difference between nations and languages. Nations determine keyboard layouts, not languages (the French, Canadians, and Swiss all use different keyboards to type the French language - azerty, qwerty, and qwertz). But see more below. I tend to disagree with this statement. There are a couple of language (a dozen at most) that are used in several countries in the world (like Spanish, French, Portuguese, German, English,...). For those languages, and for those countries, your proposal would be sane. Alas, there are another 150+ countries with even more languages that don't belong into this category, and where the relation language = country strongly holds. So, maybe this would make sense for several keymaps, but it wouldn't for most of them, especially since one may want to use a *language* while in other country -- and many users (especially novices) will make mistake if they're located in Germany, and then choose Germany as their keymap (not knowing that they're actually setting a keyboard map because they're just honestly stating their country of location), even though they want to type in English. So, I cannot see any advantage to the naming scheme you seem to be proposing, yet there are many disadvantages. Actually, another problem, as I see it, is that countries tend to use several languages, and it's *more* common that the same layout be used in different countries for the same language, than the opposite (the example you give for French, and qwerty, qwertz and azerty). So here we are. Do anyone on i18n have an opinion either way? I feel that keyboard layouts are national, and for the countries like Switzerland, the specific changes could be selected by choosing a mapping of ch(fr) or cd(de). Again, it's the minority of countries that have this kind of situation (and, at the same time, this kind of need), and I have expressed my doubts above. This is kind of an odd request and has to do more with the keycodes than the symbols. But, if all the files distributed with XFree86 used the new RLGO symbols, then the only problem would be for users who were doing customisation with xmodmap or who had their own xkb files that hadn't been sent to XF86 for inclusion. Or perhaps there's a way to preserve the compatability. I am all for it -- I don't like calling that operating system of theirs a win (as in victory), so I'd agree on this change (even though that would break compatability for some of my keymaps I am distributing outside of XFree86 main distribution). Still, I believe XF86 supports adding several different symbols that map to the same key code. Cheers, Danilo PS. I am probably a little biased, because I come from those other 150 countries, but I hope I have made at least a couple of valid points. ;-) ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
, 14. 2003. 17:35:10 CEST Frank Murphy :
I'd go for:
key AE01 { [ 1, exclam, any, any ] };
(I'm not sure if your idea would work like this -- if it would,
then this is unneccessary burden).
It's already done with only two levels in the pc/us keymap. I don't
see a reason to add the 'any's. The point was to move the generic us
layout from pc/us to pc/latin so that sun/, sgi/, etc could include
them without getting any PC-keyboard-specific baggage (like function
keys or whatever).
Yes, but I am not sure if just using [ 1, exclam ] would allow
*redefinitions* of the keys on the higher levels (where I've put
any's). This was just a technicality, which depends on the actual
implementation of XKB, and I'm not certain on this (I would have to
check).
Though, while I don't know if simply [1, exclam ] would be enough, I
am certain that putting any's in would be enough, and it would work as
you expected. (any's are actually placeholders which can be redefined,
they're equivalent with NoSymbol, but shorter to type, and more clear
in this context).
The problem is that there is no English-language keyboard layout, nor
is there a German-language layout. There are different layouts for
Britian, Ireland, Canada, Australia, Germany, Switzerland, and
Austria. So saying German or French or English does leave doubts: is
this a keyboard from France or does this keyboard allow me to type
the French language?
Yes, for a dozen of languages like the ones you're mentioning, there's
this obscurity. For *most* of the other languages and nations, there's
no collision.
In any case, just for this reason is the latter proposal about
providing *both* country based and language based.
(I was just arguing against *country-only* based keymap names. That's
the whole point. I don't mind country based keymaps, if there are also
language based keymaps)
True, but that's really the problem with yu, isn't it? :)
Nah, it was to imply that your list was incorrect, and based on wrong
assumptions -- the codes you listed were not national, but some were
linguistic (sr is a ISO 639 code for Serbian *language*).
The others, like de, es, fi, fr, hr, it, mk, nl,
no, pt, ro, ru, sk, th, tr apply to *both* language
and country (actually, these are the ones I know about; there
are probably others).
The problem is that de, es, fi, fr, nl, and pt have different keymaps
depending on the *nation*.
As much as 6 out of a list of 15? :-)
I think everything is clear -- we need to provide both nation-based
and language-based naming, if we're aiming for consistency, and want
to be sure that it won't be a problem in the future to assign a name to
a keymap.
I'd like to us an ISO standard for the filenames. For the description
of the group name, I would bet that we're constrained to 7-bit
characters. Besides, they are all in English now. Plus, in the ISO
document, the country names are listed in English.
Yes, the ISO codes themselves are using only English alphabet, so no
problem there.
I think this is a bad idea. Differentiating based on case can be
problematic (as was pointed out). However, I would think that using
ISO 3166 2-letter national codes and ISO 639 3-letter codes would
work OK. Besides, most of the current entries already follow this.
Depending on how you look at this :-)
I've already pointed out that many of the languages (uhm, nations) you
mentioned actually use the ISO 639 two-letter code ;-) Or was it the
ISO 3166 country code?
If we don't ask the authors, we can only guess -- and guess what? My
guess is different from your guess ;-)
I know I'll be a bit boring, but if case differentiation is a problem,
I'd go for providing new namespaces for each: nation/ and language/
(perhaps in shorter forms of n/ and l/).
But I wouldn't encourage a large proliferation of these. For European
and North South Amarican keyboards, recommend the 3166 code. For
Asian and Arabic keyboards, recommend the 639 code. But don't go wild
with all the possibilities, otherwise we end up with the pt(BR)/en
(US) problem that Andrew Aitchison mentioned.
As I pointed out, it's a minor work for someone maintaining the files
to provide *both* possibilities.
The problem, as Andrew Aitchison and you see it, is not a problem in
my regard -- everyone has a choice which can be made: choose by the
language, or choose by the nation.
Of course, this would cause *major* breakage for old applications
which rely on one layout being there with a specific name.
The only applications that should care would be the installation
programs.
If systems are single-user, which defeats the purpose of X network
transparency. In multi-user environments, you cannot expect every user
to use the same language in every occasion.
I would actually prohibit all 1-, 2- and 3-letter files in these
directories unless they were ISO codes. (Otherwise, we end up with
the Latin America/Laos problem.)
I'd prohibit 1-letter
Re: [I18n] Bug #122: US Intl keyboard mapping missing c with cedilla.
, 17. 2003. 15:18:18 CEST Hans Deragon : There is no AltGr key on a standard US keyboard. And on usual US intl keyboards, at least those I used on MS windows or when no locale was set under Linux, apostrophe c generates c with cedilla. So now what? I strongly believe that the standard is apostrophe c. Now how am I supposed to generate a c cedilla on a US keyboard when no AltGr key exist? I guess some references to the standard are appropriate, besides it's like that on Windows, no matter how insane is that. Of course, I'm no authority here, so you might just as well ignore me. OTOH, XFree86 aims for consistency, and there's definitely a lack of it in some places. For instance, en_US keyboard map (I'm talking of the one shipped with XFree86 4.3.0) contains dead_cedilla on AltGr + = (if you don't have AltGr, use your right Alt key; sometimes it's just darker, and sometimes there's no difference). And, as Keld noticed, there are quite a few differences between en_US and Danish, Swedish, etc. Still, some inconsistency is inevitable, because that's what users need, and what relevant standards prescribe. So, in order to get c-cedilla, you'd do the following: Right-Alt or AltGr + =, followed by c. What language use c with an accute accent BTW? My point is that we should keep the standard going with languages that do not have any use for c with an accute accent, such as french for example. I'm not quite sure how many languages make use of c-acute (well, latin transcription of my own mother-tongue does, but I don't consider my language to be mainstream, as well as Croatian, Bosnian and Slovenian). The thing is that US keyboard cannot and shouldn't be more suitable to US citizens also using French, German, or any other language. It should be suited to US citizens writing English. Everything else is just extra, and the way to provide most (to satisfy most people, rather than satisfy the majority [if it's the case that majority of US citizens use French as their second language]; note the difference) is via three level mapping. Perhaps Compose key is also used. Again, I'm no authority, I have no influence on XFree86 code, so if you wish, feel free to ignore me. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Bug #122: US Intl keyboard mapping missing c with cedilla.
Keld Jørn Simonsen wrote:
So, in order to get c-cedilla, you'd do the following:
Right-Alt or AltGr + =, followed by c.
Why is AltGr + , not used for dead_cedilla ?
It seems more intuitive?
I don't know. It's all in the file /etc/X11/xkb/symbols/pc/latin.
The basic variant has this definition for comma key:
key AB08 { [ comma, less, horizconnector, multiply
] };
while type2 used throughout Northern Europe in the same file has (I
guess that's what you mentioned):
key AB08 { [ comma, semicolon, dead_cedilla, dead_ogonek
] };
Again, I don't know who is the author of basic latin layout that's used
in en_US, nor the reasoning behind it (actually, I don't even have any
idea what horizconnector is).
One good thing about X is that you may have different keyboards,
also for en_US. So if there is enough interest we can make alternate
keyboards available for en_US.
Yes, AFAIK it's only the matter of adding to en_US file eg.
partial default alphanumeric_keys
xkb_symbols north {
include pc/latin(type2)
name[Group1]=en_US;
key RALT { type[Group1]=TWO_LEVEL,
[ ISO_Level3_Shift, Multi_key ] };
modifier_map Mod5 { RALT };
};
Then, it can be called with setxkbmap -layout en_US -variant north,
or something along those lines.
Also, there's no explicit relation between locales and keyboard maps.
Cheers,
Danilo
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XKB: ISO_Level3_Shift in group2
Behnam Esfahbod wrote: But when I use a key, in group 2, with RALT, a ? will print. Try setting the correct locale for the corresponding application (LC_*, LANG,...), and see if that helps. Eg. export LANG=sr_YU.UTF-8 export LC_ALL=sr_YU.UTF-8 # bash syntax for Serbian language or use the setenv in C shells. Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Sixlevels and strange state changes with Control
Regards,
Ivan Pascal wrote:
Did you make your mind on the _XKB_{ALT|CONTROL}_FALLBACK_TO issue?
Yes. Since there are not more opinions I can write a summary.
We have three suggestions: my one with environment variables, Vasilis's offer
with a trying all groups in turn and your one.
Of course, my approach is worst. I just chose a way that is simplest for me.
The Vasilis's suggestion is better. In this case an appropriate group search
is invisible for users but quite reliable. Of course, I can imagine a situation
where such behavior can be considered as unexpected and unwanted one (I mean
a user would like Xlib fallback to the second or the third group but it gave him
the first one). But I think it's rather an imaginary case and will never
happen.
If one wages the shortcomings and development effort, Vasilis' idea is
certainly the best at the moment.
Your offer looks like an ideal. Certanly, to have a separate map for
a fallback (actally it doesn't need to be a full xkb group but just a simple
one-level map) and allow a user to choose it by xkb options if he want, is
a best approach. But what you describe is an external look only. To make it
we need some serious changes in Xlib, xkbcomp, servers internal structures and
maybe in the protocol of an XKB extension.
I quite realize that this would be more than a simple task, and would
probably require changes to XKB protocol. Even more because it would not
be the XKB style to make this possible for only two *preselected*
modifiers, but for any, be it virtual or real (though, it might be
reasonable to insist on them being real). It appears to me that it would
require addition of entire new category of XKB settings, one that
would go along with keycodes, compatibility, types, symbols and
geometry and others (lets imagine calling it modsymbols). How do you
feel with the inclusion of such category? Would it be too much, or
acceptable?
This would involve modifications to some (if not all) struct's used in
the source code, certainly changes to the xkbcomp. And probably a few
places I don't even know about at the moment.
If there is a volunteer for this task I would be glad but it isn't me
at least now.
I will consider doing it, but I make no promises whatsoever. If I get
anywhere near the finish in the meantime (next few weeks), I'll be sure
to inform you, and this list.
I made a patch according to Vasilis's suggestion. You can test it.
Thanks for the patch. I'll test it right away!
Since one of the concerns for me is how will it work for the average
user who installs only the release, will this patch be included in the
XFree86 4.3.1?
Cheers,
Danilo
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XKB: direct switch from group1 to group3
Regards, Torsten Foertsch wrote: I'd like to directly switch from group 1 to group 3, i.e like hitting iso-next-group twice. Is that possible? Not that I tried, but did you try setting action = LockGroup(group+=2) for some key (in the compatibility section, for instance, in the $XROOT/lib/X11/xkb/compat/iso9995-3 file) If what you're looking for is setting group 3 no matter what group you were in, maybe you should try action = SetGroup(group=3). Of course, choose a keysym of your liking, maybe even one of the symbols you don't actually use (ISO_Last_Group, or whatever). Cheers, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XKB: Control shortcuts (CTRL+X) with Serbian cyrillicand more
Ivan Pascal wrote:
Danilo Segan wrote:
It all works fine, but the problem arises with the usage of CTRL+key
combinations. If I put en_US as the first group, then they use keys from
group1 no matter what group is active. But, in any other case, they use
the key mappings from the current group.
There is an XKB feature that is completely undocumented, unfortunatly.
The XLookupString (and so X{mb|wc}LookupString too) procedure having Control
modifier in a key event tries to make a 'controlized' code from the symbol
got from the current layout.
If this attempt fails, the procedure changes an XKB group to the first one
and repeats the 'controlization' attempt.
(The documentation is a source code of XLookupString in xc/lib/X11/XKBBind.c).
It seems to me that there's also something related on line 728 in
XKBTranslateKeySym (actually, it's the only other place where
ControlMask is used to treat Control specially). Of course, all this is
performed starting with line 878.
What about suggesting to enforce (if anything is enforced) in
XkbToControl() only? Isn't it saner to have all the ifs and thens on
one place?
Since a control code can be produced from an ascii code, if a key in the
current group has such keysym you get the controlized code (the first attempt
got success). Otherwise you get the control code from the first group, if
it is a latin-based layout (the second attempt is successful) or just a code
from the first group.
This behavior can be switched on/off by setting 'Xlib XKB control bit'
XkbLC_ControlFallback or using the environment variable _XKB_CONTROL_FALLBACK
(values can be 'on/off' or '0/1'). By default it's switched on.
It seems to me that for multi-layout it's way better to have it
switched off as default.
It worked well while all keyboard maps had the 'us' map as a first layout
or were latin-based maps themself. But as you see this method doesn't work
in some multi-layout combinations.
I would offer to add another one variable like:
_XKB_CONTROL_FALLBACK_TO=group
BTW there are users who would like to have the similar option for Alt
modifier, i.e. _XKB_ALT_FALLBACK.
Any opinions?
Actually, I find hard coding any of these to be counter-productive
(including the _XKB_CONTROL_FALLBACK_TO=group, and _XKB_ALT_FALLBACK,
_XKB_CONTROL_FALLBACK).
I think that the keymap writers will be the ones who know best what will
the user expect (for example, if I have a program translated into
cyrillic, Alt would need to use cyrillic letters to access the menus,
while Control would still need to use latin letters for shortcuts like
C-A, C-S and so forth). Still, even the keymap writers would not be
entirely correct. In such cases, there should be fallback (for instance
when the user is a native english, he expects to have Alt and Control
both use his base, even though he might temporarily type some
cyrillic). This fallback should not be as simple as group1 or
groupwhatever, and it might need to be a special section in Xkb
options (eg. fallback section next to compat, types, extra and
others). For the time being, your suggestion would work if we could make
one group transparent (it would be skipped by ISO_Next_Group, and
other shift keys). The transparency matters because if one runs cyrillic
GUI, with latin Control-shortcuts, and yet uses some external keyboard
switcher, (s)he couldn't access neither the menus nor the
Control-shortcuts if he suddently starts typing Hebrew. That's the main
reasoning for separating this mechanism from groups mechanism.
The care should be also taken as to not assume Control shortcuts use
only latin alphabet, since, at least in GTK+ programs, one is allowed to
dynamically redefine shortcuts, what would lead to all sorts of problems.
At least, if you opt for your suggestion of *_FALLBACK_TO, it would be
nice to be able to set this through keymaps, by using -option
parameter to setxkbmap (or in XF86Config):
setxkbmap -layout sr,yu,en_US -option grp:shift_toggle,alt-fb:1,ctl-fb:3
Now that I think of it, this seems as a quite a good idea ;) Especially
so if one uses only standard facilities for setting XKB up (setxkbmap,
XF86Config, ...). If we want to take care of those using other
switchers, we might need something on the lines of:
setxkbmap -layout fr -option alt-fb:sr,ctrl-fb:en_US
where sr and en_US are symols/pc/ files (by default).
On my other problems I'll start a different thread, so as not to confuse
anyone.
Regards,
Danilo
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n] Sixlevels and strange state changes with Control
For the time being, at least some of Ctrl/Alt dance can be achieved
using higher levels, so here are my problems.
In the currently designed sixlevel type (one at
http://www.kvota.net/srpski/1.5/sixlevel), where LCTL is
modifier_map-ed to Mod4, it works as expected (it does select level
five) in GTK+ 2.x apps and in Xterm. But, Emacs 21.3.50.2 (it's same
with the old Emacs 21.2.1) shows with describe-key that it reads it as
if C-s-x (CTRL+S+X, not CTRL+Shift+X) is pressed when I press only C-x.
KDE apps (KWrite) don't work at all.
This is xev output when cyrillic group is active:
KeyPress event, serial 25, synthetic NO, window 0x321,
root 0x40, subw 0x0, time 12562633, (400,268), root:(403,344),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
KeyPress event, serial 25, synthetic NO, window 0x321,
root 0x40, subw 0x0, time 12563178, (400,268), root:(403,344),
state 0x44, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes:
KeyRelease event, serial 25, synthetic NO, window 0x321,
root 0x40, subw 0x0, time 12563313, (400,268), root:(403,344),
state 0x44, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes:
KeyRelease event, serial 25, synthetic NO, window 0x321,
root 0x40, subw 0x0, time 12563626, (400,268), root:(403,344),
state 0x44, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
If en_US group (third) is active, it's same except for the time, and
state which is 0x4044.
If I change the Mod4 to Control in sixlevel, and remove
modifier_map Mod4, then I experience even more problems, but only in
GTK+ 2.x apps, Emacs and Xterm. xev shows the following when cyrillic
group is active:
KeyPress event, serial 25, synthetic NO, window 0x341,
root 0x40, subw 0x0, time 14236822, (644,657), root:(650,759),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
KeyPress event, serial 25, synthetic NO, window 0x341,
root 0x40, subw 0x0, time 14237996, (644,657), root:(650,759),
state 0x4, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: d
KeyRelease event, serial 25, synthetic NO, window 0x341,
root 0x40, subw 0x0, time 14238127, (644,657), root:(650,759),
state 0x4, keycode 40 (keysym 0x64, d), same_screen YES,
XLookupString gives 1 bytes: d
KeyRelease event, serial 25, synthetic NO, window 0x341,
root 0x40, subw 0x0, time 14239154, (644,657), root:(650,759),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
The main difference I see is that with Mod4 state is 0x44, and with
Control is 0x4. Also, XLookupString returns 1 byte with Control, where
none is returned with Mod4.
This is how programs act with Control as level five modifier:
- GTK+ 2 (gedit, Galeon,... ) simply pressing a key acts as if
Control+key is pressed (so, typing a cyrillic a tends to select my
entire text, instead of outputing ).
- pressing a Control+H while cyrillic is active only acts as if Control
is a simple LevelFive modifier (it's not set in modifiers), so latin h
(that's what is on level 5 for that keycode) is output.
preserve[Control]=Control doesn't help.
It seems to me that appropriate would be to have state 0x44 and
XLookupString to receive d when CTRL+D is pressed. How can I achieve that?
Maybe I need to modify interpret sequences in compat?
The symbols file in question is at http://www.kvota.net/srpski/1.5/sr
and it is a Serbian keymap containing several layout, but maily,
six-level cyrillic (1. cyrillic lowercase, 2. cyrillic capitals, 3.
extra symbols, 4. extra symbols, 5. english lowercase, and 6. english
uppercase), and six-level latin (1. latin-serbian lowercase, 2.
latin-serbian capitals, 3-6 same as cyrillic).
And, another suggestion. Now that we have multilayout for groups, is
there a chance to get merging for levels? Before, we could use
AE10 { [ ], [ ], [ a, A ] }
to specify that only group3 is overriden, but now we might want
AE10 { [ , , , , a, A ] }
to specify that only levels 5 and 6 are to be overriden.
Thanks in advance, and best regards,
Danilo
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XKB: Control shortcuts (CTRL+X) with Serbian cyrillicand more
Danilo Segan wrote: ... At least, if you opt for your suggestion of *_FALLBACK_TO, it would be nice to be able to set this through keymaps, by using -option parameter to setxkbmap (or in XF86Config): setxkbmap -layout sr,yu,en_US -option grp:shift_toggle,alt-fb:1,ctl-fb:3 Now that I think of it, this seems as a quite a good idea ;) Especially so if one uses only standard facilities for setting XKB up (setxkbmap, XF86Config, ...). If we want to take care of those using other switchers, we might need something on the lines of: setxkbmap -layout fr -option alt-fb:sr,ctrl-fb:en_US To make it more clear, here these would not be fallbacks, but rather definite, so names should probably be on the lines of alt+syms: and ctrl+syms: Regards, Danilo ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] XKB: Control shortcuts (CTRL+X) with Serbian cyrillic and more
While developing a bit more advanced (and correct) keyboard for Serbian, I came across several problems. I use the multi-layout features of XFree86 4.3.0. The task: Standard alphabet for Serbian is cyrillic, but latin transcription is used as (if not more) widely as cyrillic script. So, I created two different symbol maps in one file pc/sr (actually, a few more, but that is not relevant) named cyrillic and latin. Using the new features, one should be allowed to load the maps with setxkbmap -layout sr,sr,en_US -variant cyrillic,latin, -option grp:shift_toggle It all works fine, but the problem arises with the usage of CTRL+key combinations. If I put en_US as the first group, then they use keys from group1 no matter what group is active. But, in any other case, they use the key mappings from the current group. To try to be more clear: If groups are sr(cyrillic),sr(latin),en_US pressing CTRL+S would generate CTRL+ (cyrillic S) if cyrillic group is active, and CTRL+S otherwise. If groups are en_US,sr(cyrillic),sr(latin) pressing CTRL+S would generate CTRL+S no matter what group is active. I don't understand the reasoning behind this, so I would love to be enlightened :) To me, it seems to be a bug, since I couldn't find any special actions being defined for use in en_US. And to also mention that it's the same if I replace en_US with some other latin mapping (eg. Czech). Because this is not the desired behaviour for me (I want CTRL+S to be generated even in cyrillic, without forcing user to put en_US in the first group), aslav Ili and I have made a SIX_LEVEL keyboard that puts the basic english alphabet at levels five and six. If I put the Control as a level five modifier in a definition of SIX_LEVEL* types, Control gets discarded and I can just use it as level-five shift. If I use preserve[...]=Control, I experience problems in GTK+ 2.x apps (Galeon, gedit) where just pressing any character gets interpreted as if Ctrl is already pressed (eg. pressing A in cyrillic map acts as if CTRL+A is pressed). So, I had to define a Mod4 as modifier for the 5th level. The sixlevel file which defines SIX_LEVEL types is located at http://www.kvota.net/srpski/1.5/sixlevel (it goes in /etc/X11/xkb/types and is included in file complete). The symbols file is at http://www.kvota.net/srpski/1.5/sr (or you can download both in http://www.kvota.net/srpski/sr-1.5.tar.gz 4kb file). Still, I experience some weird behaviour from time to time, and I'd like to hear any advice on setting this kind of layout without insisting on group order. Also, I'd care to hear how to output/repeat a modifier if I use it for switching levels (eg. if I put Control to be used for level5 shift, then I also want the Control modifier to stay active; preserve causes all the weird problems mentioned above). As a guide, I used both Unreliable guide to XKB by Doug Palmer (if I remember correctly, otherwise please excuse me), and XKB Guide by Ivan Pascal. Also, I've read bits of XKBlib and XKBprotocol documents, and of course the README.XKB* supplied with XFree86 4.3.0. Best regards, Danilo egan PS. I also noticed that pc/us map doesn't define symbols for BKSL, so it cannot be used with any mapping which redefines it (mine being a prime example). I'd call this also a bug! ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
