Re: [I18n]new xkb lt layout
On Tue, Dec 10, 2002 at 05:27:18AM +0200, Nerijus Baliunas wrote: > Hello, > > I tried the new pc/lt layout. When I press Right Alt with the numeric > keys (1, 2,...) I get correct Lithuanian letters aogonek, ccaron, etc as > it should be. But when I press Ctrl-Shift (my toggle for layouts - I have > Option "XkbOptions" "grp:ctrl_shift_toggle" in XF86Config-4), I get > onesuperior, twosuperior from pc/latin layout when pressing 1, 2. > While with an old lt layout I get Lithuanian letters here also. What > should I change in pc/lt? > > Regards, > Nerijus If I understand your problem correctly the original li map is okay, but if you switch to latin (to other group) you don't want _exactly_ the latin behaviour but a li-modification of latin (with some keys overridden to accented letters). I think the correct solution is a redefinition of a portion of latin map with desired keys (as in li) which should be put in a separate section of li symbol map. Then the user could ask for described behaviour as: XkbSymbols ¨us+li(us_li_accented),li¨ or for the original latin and pure li as XkbSymbols "us,li" I believe this could be a general scheme for such changes. Maybe it would be nice to use a general naming scheme for such "extensions". What do our gurus think? ;) Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Locking Level 3 shift with XKB
On Tue, Dec 03, 2002 at 05:25:15PM +, Séamus Ó Ciardhuáin wrote: > Hi, > > I've created and submitted an Ogham keyboard layout. It's been pointed out > to me that to correctly support the standard for this, I need to change the > effect of Caps Lock. > > It needs to be a locking level 3 shift. In keysymdef.h there is a > definition for "ISO_Level3_Lock" but I haven't been able to make it do > anything. > > All that's needed is for CapsLock to select Level3 and lock it, rather than > Level 2. Can anyone help? > > Thanks, > Séamus See types definitions section in README.enhancing.sgml when it does hit CVS or http://www.tsu.ru/~pascal/en/xkb/internals.html Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Syriac keyboard layout
On Sun, Nov 24, 2002 at 07:58:11PM +0100, Juliusz Chroboczek wrote: > PS> Only use named keysyms if they already are in keysymdef.h > > Yes. > > The converse is also true: do not use a Unicode keysym if there is a > named keysym. > > Juliusz May I please for a paragraph or two in 'README.enhancing' (xkbcomp tree dir) file about this topic (keysyms vs. unicode)? Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Problem with CapsLock in french keyboard
On Fri, Nov 22, 2002 at 01:18:08PM +0100, [EMAIL PROTECTED] wrote: See README.enhancing (in xkbcomp tree), section about xkb key types. This might help you. Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Making multi-layout the default (was Re: [I18n]Farsi Keyboard Layout)
> Yes I see. > As for me I prefer variants. Since we have a two-level model Layout/Variant > (or even three-level with XkbModel) it would be better to tie these levels > to other terms such as a Language (or country) and a variants inside the > language layout. (Just my opinion, of course). > Note that there are also XkbOptions which can be used for 'minor changes' > common for all layouts. > > > How would this look if qwerty was a variant of cz? > > Obviously, like cz(qwerty_winkeys). > Have you seen a complete list of subsections in the Hungarian keyboard map? :) > > BTW it is one of reasons why I'd suggest to pay attention to the new > incarnation for a 'description file'. > In my opinion although the layout names are pretty clear the variant > names shouldn't be used for a manual XKb configuration. Of course you > can give them quite understandable names but comprehensive descriptions > are better. I see. Well I don't have a strong opinion on this topic. I posted a conservative patch for cz and sk maps to supply missing variants where I tried to minimalize needed combinations (which could greatly increase with qwerty as a variant). But as I said, I'd be glad if a common pattern of naming, variants and descriptions is made and the files adjusted accordingly ;) Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Making multi-layout the default (was Re: [I18n]Farsi Keyboard Layout)
On Tue, Nov 19, 2002 at 08:38:16PM +0600, Ivan Pascal wrote: > >- Also a new directory/tree for 3rd party stuff would be nice > >- Some maps are still not all correct. Speaking for myself, cz_qwerty > > map is missing, for instance. Should I add it (is it used to > > be in 4.2.1) or not > > Oh, sorry. I can't guess how I missed it. Bah, no problem to add it. The only problem is where to... > > > (I mean -- the role of 'variants' is not very clear now)? > > What is wrong with variants? There is nothing wrong with variants as such. Not even with maybe funny looking but perfectly logical XkbVariant list you introduced below. But (as you can see on your own example below) are mostly about some minor changes (winkeys, missing usefull keys or so) but it's not about layout changes. Maybe there is no such other braindead map as cz/cz_qwerty but it doesn't seem obvious to me. For example: cz(winkeys) looks okay, but cz_qwerty(winkeys) is also meaningful. How would this look if qwerty was a variant of cz? > I should explain. Like the XkbOption now can be a list of layiouts > the XkbVariant can be a list of variants too. But since not all layouts > need a variant the list can looks like > XkbVariant ",,qwertz" > I know it seems ugly but I can't invent something better. On the other > hand in most cases you can specify the variant directly with the layout > XkbLayout "us, cz(qwerty), ru(winkeys)" > (It's a rather trick becouse the variant is not necessarily a subsection of > a symbols file. But in most cases it is.) Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Making multi-layout the default (was Re: [I18n]Farsi Keyboard Layout)
On Tue, Nov 19, 2002 at 08:19:53PM +0600, Ivan Pascal wrote: > No objection. > I can make a patch in nearest days. > But there is one issue. In existent layouts all non-latin layouts actually > are two-level (two groups) maps where the first level is an US English > and the second one is the national layout itself. Should I make the same > defaults for the new maps (it's possible but means a lot of lines in the > rules file) or let the national layout now means the layout itself and > nothing more? (None that now it can be easy conbined with any other layout.) > The first approach is more habitual for X users but the second one seems > to me more logical. Wasn't it the reason for splitting it into single group files? I think it is one of them. So moving the mess into rules files wouldn't make sence. As far I know those maps have us map in group1 mostly for historical reasons. It could be also group2 or so. For those who haven't discuss this let me explain on cz map: On cz win32 platform the rough equivalent of cz is the only widely used map. There is no us keyboard map unless you specifically checked it extra in installation. However this hasn't been always true. Internacionalization was quite slow even in dos/win world, so many people used to us keyboard writing without accented letters (which is not very clear but understandable). And programmers (formerly most of computer users) had problems typing first US row symbols (@#$%^&*...) on earlier cz layouts. They solved it by instant switching cz and us keymaps (their only problem is that cz, is as its preimage german map, us qwertz but us map is qwerty - so they need another modification map - cz_qwerty). And they are now used to it. So the situation is that "normal" users, less technical use pure cz keymap while programmers and most of "power users" use cz_qwerty mostly with a combination with us map (for their beloved instant layout switching). Some like us as default keymap, some like cz more. It is up to their personal preference. The xkb configuration "us,cz,de", "cz,us,de" etc. seems to me powerful enough to avoid further complicating xfree86 rules file. See czsk keymap - there are all possible combinations defined. I'd leave it simple. For most people it will be natural, I think. Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Making multi-layout the default (was Re: [I18n]Farsi Keyboard Layout)
On Mon, Nov 18, 2002 at 08:45:20PM -0500, David Dawes wrote: > OK, it's clear from this and other reponses that there's still a lot of > open issues, many of which are definitely beyond the scope of 4.3.0 and > are things we should try to solve for a later release. > > Would it be reasonable to change the default to the new maps (and provide > a way of forcing the old ones) for the next few weeks, so that the new > ones can get more exposure? We can then decide at that time whether to > change the default back to the old maps before for the release. With this > method we'd keep the old ones around unless we are confident by 30 Nov > that we can replace them completely with the new ones. > > To summarise a timetable: > > - Change the default to the new maps now, so more people will be exposed > to them. > - No major structural change (like removing old maps) after 30 November > - Changes accepted to maps until ~mid December > - Choose which are the default (for Option "XkbLayout" "us") by > ~mid December. > > - Come up with a plan to address the other issues after 4.3.0. > > Comments? - I suggest to make a new tree where only clean stuff would go (new maps, only needed files), the current map tree should be left (preferably) as is with a reasonable 'force old' option in xfree configuration - Also a new directory/tree for 3rd party stuff would be nice - Some maps are still not all correct. Speaking for myself, cz_qwerty map is missing, for instance. Should I add it (is it used to be in 4.2.1) or not (I mean -- the role of 'variants' is not very clear now)? Your plan itself sounds very reasonable to me. That exposing may do some goodness as some apps (Java apps for example) still don't work with xkb groups - this would be more crucial with multi-layout ... Kamil ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XKB layouts
On Tue, Oct 22, 2002 at 08:27:52PM +0700, Ivan Pascal wrote: > Option "XkbLayout" "fr, il, ar" > or > setxkbmap "de,ru,ua" > > But for such composition the symbols file itself should obey some > restrictions. All keysyms in such file can occupate only one group and > it must be the first group exactly. In the same time the existent files > for non-latin based alphabets contain the national alphabet in the second > group and the files with latin based alphabets use the first group but > partially occupate the second one too. > Therefore I had to make a new file for each layout. And since all that > stuff is experimental I didn't dare to replace the existent symbols files > completely and put new files in a separate directory - xkb/symbols/pc. > > There is not any documentation yet. But I hope this explanation can help. I'm trying to reorganize and further cleanup the xkb tree due to I.U.P. changes (which are very good I think). I have some major problems with some maps and mostly with overall geometry files organization. Anyway, I'm trying to think out a reasonable organization and then I plan to finish small portions of it. I will probably put more work into documentation 'how to write' than to convert existing maps (in a blind will that someone who really knows how the map _should_, not does, behave will do it). This may clear out the air but I doubt it will be anytime soon. Anyway, feel free to e-mail me your suggestions. Kamil > > -- > 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 -- /-\ Kamil Toman | See you Soon! | /\ /---\ | My Homepage | Keywords: BB, AA-group, AA | | ~~~ | Koules, par, Linux, TeX | | http://www.ta.jcu.cz/~toman | and many others ;-0 ... | \---/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]An XKB layouts (variants, models, etc.) description.
> 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?
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?
Kamil
> --
> Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
>Administrator of | Tomsk State University
> University Network | Tomsk, Russia
Content-Description: xkb.dtd
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>allowMultipleChoice (true|false) "false">
>
>
>
>
>
>
>
>
>lang CDATA #IMPLIED>
--
/-\ Kamil Toman
| See you Soon! | /\
/---\
| My Homepage | Keywords: BB, AA-group, AA |
| ~~~ | Koules, par, Linux, TeX |
| http://www.ta.jcu.cz/~toman | and many others ;-0 ... |
\---/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]setxkbmap issues
> Hello! > > I've been working on kxkb (keyboard switcher for KDE) which calls > setxkbmap and found that it's really slow. It became really critical now > that kxkb can do per-window switching. I have chased the problem down > now. With average switch time about 270ms on my K6-500 around 240 ms is > spent in KxbGetKeyboardByName() > Is there any way to speed it up or bypass this function calling some others? There's a proposed solution to avoid using setxkbmap most of the time. We refer to it as single-group xkb layers. If you are interested please send me an email (I. Pascal also knows the proposal). Kamil > > Thanks, > Andriy > > P.S. BTW the code of setxkbmap looks really ugly, that would be nice if > it was brushed up with indent or other buitifier. No hard feelings - > just my opinion. > > ___ > I18n mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/i18n -- /-\ Kamil Toman | See you Soon! | /\ /---\ | My Homepage | Keywords: BB, AA-group, AA | | ~~~ | Koules, par, Linux, TeX | | http://www.ta.jcu.cz/~toman | and many others ;-0 ... | \---/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]xkb layouts and variants
> On Fri, Jan 11, 2002 at 12:05:17PM -0800, Andriy Rysin wrote: > >Hi! > > > >Why don't we keep all those different layouts like ca and ca_enchanced, > >lt, lt_a, lt_std and lt_p pl and pl2 keep in one file (ca, lt and > >pl respectively) and use variants inside the layout file? It really > >annoying to see 4 lithuanian layouts in the list or couples like "pl" > >and "pl2". > >And it's really easy to use variants in setxkbmap: > >setxkbmap "ua(basic)" or setxkbmap "ua(winkeys)" > >or another way > >setxkbmap ua -variant basic or setxkbmap ua -variant winkeys > > > >More than that - recent kxkb from KDE allows you to "choose" of existing > >variants from inside the layout, which makes it really convinient. > > > >Thus we would be able to keep as many variants as anyone want without > >polluting common namespace. > > I agree. It'd be good it someone could clean these up after 4.2 is released. Hi, I've discussed with I. Pascal another xkb configuration cleanup (single group design / layers for recall). Unfortunately I won't have time for this till about March but the proposal is known - if someone wanted to clean this stuff he should also consider this too if possible. Thanks, Kamil Toman > > David > -- > David Dawes Email: [EMAIL PROTECTED] > Tungsten Graphics, Inc http://www.tungstengraphics.com > Founder/President, Release Engineer Phone: +1 570 764 0288 > The XFree86 Project, Inc http://www.xfree86.org/~dawes > ___ > I18n mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/i18n -- /-\ Kamil Toman | See you Soon! | /\ /---\ | My Homepage | Keywords: BB, AA-group, AA | | ~~~ | Koules, par, Linux, TeX | | http://www.ta.jcu.cz/~toman | and many others ;-0 ... | \---/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
