X Window Keyboard and around's Journal|
[Most Recent Entries]
Below are 14 journal entries, after skipping by the 20 most recent ones recorded in
X Window Keyboard and around's LiveJournal:
[ Next 20 >> ]
[ Next 20 >> ]
|Sunday, March 5th, 2006|
|Sunday, January 29th, 2006|
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.
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?
|Saturday, January 28th, 2006|
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.
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.
glib is an actively maintained library
glib, properly used, has a lot of cross-platform functions which can be used
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).
Both G and K people will be happy
We need to find something reliable, stable and licence-compatible
3. Create own data structures
Minimal footprint, only necessary stuff etc etc
Some major effort. New series of bug would be introduced. Overall - looks just another NIH-syndrom thingie...
My personal preferences:
#1, #2, #3.
|Tuesday, January 24th, 2006|
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.
|Thursday, December 29th, 2005|
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...
|Tuesday, December 6th, 2005|
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.
|Saturday, November 26th, 2005|
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
|Thursday, November 10th, 2005|
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?
|Monday, November 7th, 2005|
Why GNOME does not use flags
I am sick of constantly coming requests to use flags for the keyboard switching, so hoping to reduce the traffic, I'll just put here a couple of links:
- The archive of desktop-devel-list for November 2003. The huge flame thread with the subject 'No Flags "POLICY"'
- Debian maintainer resigned because of the Taiwanese flag shipped with Debian
- A very upset user complained about using incorrect name for his country
That's life as it is...
|Thursday, November 3rd, 2005|
xkbcomp + libxkbfile = :-E
TWIMC: xkbcomp and libxkbfile contain bugs which make translation XKB->XKB or XKB->XKM incomplete. These bugs are not seen in "trivial" configurations but if user/admin creates non-trivial rules, the problems go on the surface...
The code is neither really commented not documented (and I love dawes for proper commit messages in xfree CVS), so it will take some time to locate the points of the problems and to fix them... BTW, any ideas on how to debug kbd module in X server? Current Mood: Slightly angry
|Sunday, October 30th, 2005|
Announcing the community
This community is about two things. Keyboards and X Window System. Anything related to these matters is a valid topic here.
In particular, XKB extension is of interest. Layouts, utilities etc etc. Problems, bugs, complaining - whatever. XOrg, XFree, commercial X servers - whatever.
Xmodmap (classic X Window keyboard machinery) is a valid subject as well.
Feel free to discuss input methods, composing, keyboard PnP etc etc
Configuring the keyboards is a tough business sometimes - so it is a first priority topic here.
Hopefully here will be people here to discuss and comment, to ask and to answer. Everyone is welcome.