xkb directions and feature-removing changes

XKB configs seems to be very flexible (and arcane, too, of course) system. I deduced from the different sources (such as this community, and Keith Packard's papers) that it's very possible to have this system redesigned and wonder, won't the resulting system will be less flexible than current (as GNOME folks do, removing features as "confusing").

If the question is too wide, I might narrow it: is there active effort in redesigning xkb, and if it is, is there way to suggest particular features which should be supported in the result: I have the xkb config written nearly from scratch (due to the fact I was unable to figure out how to compose and tweak existing layouts to make it work exactly as I wanted), and it will be very frustrating if I unable to tweak future configuration to resemble my current settings.
Square 100x100
  • pbw

Compose map for SuSE/KDE

My keyboard configuration in SuSE 10.0, using KDE, is missing the composition of 'v' with upper and lower case 's' and 'z' (s and z with caron), and no doubt others. My locale is en_US.UTF-8. These characters are available at the VT consoles (although there is a long-term problem with the flakness of compose in the consoles), but not in KDE.

Can I access the compose mappings? If so, how?
  • simosx

Keyboard configuration in GNOME

It is very encouraging that the keyboard configuration in GNOME works rather seamlessly, for the languages that the X Input Method is suitable to use. For example, to get a stock installation of Ubuntu Linux 5.10 to support both US English and Brazilian Portuguese, simply follow the steps at
How to enable US English and Brazilian Portuguese in GNOME

Still, there are some users that either encounter bugs in the X Input Method or simply stumble upon usability issues in the applet, and need extra support.
I envision the work carried out in the keyboard applet will solve these issues and will be able to be used collectively as the single point of reference for end-users to set/configure the input methods for their languages.
smiling duke

libxklavier: to glib or not to glib? Part 2

After yesterday's discussion on IRC, we found that actually we have 3 options for introducing complex data structures to libxklavier:
1. Add dependency on glib.
Pros:
glib is an actively maintained library
glib, properly used, has a lot of cross-platform functions which can be used
Cons:
KDE people do not like the idea of having dependency on glib. Though some optional software has already introduced that dependency
2. Add dependency on "independent" (neither G nor K) 3rd party C library (with compatible licence).
Pros:
Both G and K people will be happy
Cons:
We need to find something reliable, stable and licence-compatible
3. Create own data structures
Pros:
Minimal footprint, only necessary stuff etc etc
Cons:
Some major effort. New series of bug would be introduced. Overall - looks just another NIH-syndrom thingie...

My personal preferences:
#1, #2, #3.
Square 100x100
  • pbw

XKB configuration

I haven't looked into the code for xkbcomp, so much I this will be speculation. Some things I know.

The XKB configuration system is irretrievably arcane. The semanatics of the XKB configuration files is, to the casual user who wants to implement their new keyboard, incomprehensible.

I first attempted this in 2000 for a Dell laptop with a GB keyboard. I managed to get something working, and to retain my sanity. I've ventured in a few times since, most recently to generate a keyboard for a ThinkPad G41. I managed by replacing all of the relevant configuration files with new, minimal versions designed around the thinkpad, and had this working in Gentoo. However, when I switched to SuSE, any attempt to invoke my keyboard files resulted in the complete loss of keyboard function.

What it seems to me is required is the rewriting of the whole of the configuration database in terms that the casual keyboard configurer can comprehend. Start from the output of xkbcomp and work back, developing a consistent way of expressing and redefining key values. Keep it as simple as possible. Write it in a higher level language. For defining a keyboard, computing efficiency is not a priority. Sort out performance issues afterwards., remembering that the vast majority of users are getting their X keyboard services from their own desktop.

I don't know wheter this approach is feasible, but I do know that a radical redesign of configuration is needed.
smiling duke

libxklavier: to glib or not to glib?

So far, libxklavier was considered as desktop-agnostic library. Since the format of the XKB directory is getting more complex (very soon), the library most probably will be using glib for its data structures - so K-people, E-people (which were never really interested anyway) would have some minor troubles if one day they decide to use it...
smiling duke

(no subject)

The problem with Macedonia/FYROM strikes back in the comments to the latest GNOME Journal issue. I still think that in the software, the country name should be spelled the way people of the country itself want to spell it in English (in "C" locale, I mean) - and then, it's up to the translators... This rule is universally applicable to all internationally recognized countries.
smiling duke

LevelOneOnly & useModMapMods

After a month of digging in XOrg xkb-related sources, I found that using LevelOneOnly and "useModMapMods = level1" should most probably be banned in the compatibility files (or at least used VERY carefully).
These keywords make the code check for the first level of the first group - which creates problems for other groups (and makes the first group very special).
So, after this month I will remove a line or two in compat/misc...

For more details, read here: http://pascal.tsu.ru/en/xkb/gram-compat.html

P.S. Most exciting impression from XKB code: in programs/Xserver/xkb/xkbAction.c, there is a number of functions returning XkbAction (not a pointer, the struct itself!). And, for some reason, some retvals are declared as 'static' - without any real need (again, the code returns struct, not pointer).
  • Current Mood
    angry angry

Understanding Relationship of Keyboard Files

I am trying to find documentation that describes the relationship between all the Keyboard files, and how to create keyboard files for a language. Also where does one "check in" keyboard files so that they flow down to all Linux distributions?
If I could get a mentor to assist with doing this correctly, it would be great. The Tajik keyboard seems to be correct about every other distribution. It seems like we "change" certain characters in a shared en_US.UTF-8/Compose file for Tajik, then other Central Asian language teams "correct" the characters for their language. How do we get out of this shared arrangement into our own keyboard definition? There are so many files in /usr/X11R6/lib/X11/locale such as Compose.dir, locale.alias, locale.dir In this directory there is no tg_TJ folder as there are with many other languages. Under /user/share/locale/ are folders tg, tg_TJ, tg_TJ.UTF-8 why are there three? Why not just the UTF-8? In etc/X11/xkb/symbols/compose/ there is a tj file (country not language?) how or when does this get used compared to the Compose file? Is there a how-to for those of us that need to do this just once? How or where do we check it in? I'd sort of like to learn how to do this. I'd prefer to get a mentor to help me through the process. Also, which bug list covers these files?
Thanks
Roger Kovacs