Re: Half-QWERTY keyboard support: help!
On Tue, Mar 11, 2003 at 10:39:11PM +, [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2003 [EMAIL PROTECTED] wrote: I'd like to add support to XFree86 for 'half-QWERTY' typing. I'm not sure whether this fits into the X keyboard scheme, because it involves [...] I forgot to add -- even if somebody can tell me the 'correct' way to do it, a pointer to the place in the code where a simple hack (on the level of keysyms, I suppose) could be inserted would also be much appreciated. Then I can start learning to type again, without being restricted to the linux console! Try to look in here: http://www.xfree86.org/current/XKB-Config.html (basic info) http://www.xfree86.org/current/XKB-Enhancing.html (developer's info) If you defined SPACE to be third-level modificator instead of ralt, then you could place mirrored keys into third-level and everything would be easy. If you need to preserve alt, the task is somewhat harder. Have a nice day, Kamil ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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] 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 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: 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: [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
?xml version=1.0 encoding=koi8-r?
!--
Description: XKB configuration file DTD
Author: Sergey V. Udaltsov
--
!ELEMENT xkbConfigRegistry (modelList,layoutList,optionList)
!ELEMENT modelList (configItem*)
!ELEMENT layoutList (layout*)
!ELEMENT layout (configItem,variantList?)
!ELEMENT optionList (group*)
!ELEMENT variantList (configItem*)
!ELEMENT group (configItem*,option*)
!ATTLIST group
allowMultipleChoice (true|false) false
!ELEMENT option (configItem*)
!ELEMENT configItem (name,description*)
!ELEMENT name (#PCDATA)
!ELEMENT description (#PCDATA)
!ATTLIST description
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
