I need to implement keyboard layouts for several african languages, some with complex tonal marks: acute, grave, grave with dot below, acute with dot below (these are the ones i know now, but there may be others). many of these characters do not have unicode code points of their own but they can be represented using combining diacritical marks: ie S with acute and dot below is S + U+0300 U+0323 - this is what i understand but i may be wrong so please correct me.
My question is how do you implement such solution on linux? looking at the Compose file for en_US.utf8 it seems composing sequence characters can only be mapped to another unicode code point: eg. <Multi_Key> <U10001100> <U10001100> : "'' " U1101
How do you compose keys with multi_key or dead keys that emit more than one code point?
Can this be implemented in the xkb keyboard layout/variant file? if so, how?
Where should I put geometry for IBM ThinkPad Z60m, to
geometry/lenovo? Or some other place?
And how should be model named? Currently I choose
thinkpadz60m, but this geometry also applies to most of 60/61 series (as I can see on photos).
When enabled group changing for ctrl+shift other hotkeys such ctrl+shift+left stop working...
Does anybody know a solution for this problem?
There is probably a bit too many libraries related to the keyboard - in X Window System in general, and GNOME in particular. In order to explain their not-too-complex relationships and their places in the whole puzzle, I am giving some short reference here.
Strictly speaking, this library does not exist. Well, technically it does - but it was never meant to be public. Well, unfortunately it is de facto public now - for a long while. Why? Because there are several things in XKB which have never got proper network-transparent solution. In particular - dealing with keyboard configuration in terms of rules/models/layouts/variants/options (RMLVO). In the reference X Window System implementation, libxkbfile is handling RMLVO. It was originally designed as internal library linked to X server and several command line utilities like xkbcomp and setxkbmap. It was never network-transparent, it works with local keyboard configuration database files directly - which means it cannot properly support with remote X server (except for special environments using NFS etc).
This is one of many dark corners of X - the library which should not be used by anything but X implementation internally - but it is actually used quite often.
This library is installed as a part of standard Xorg or XFree86 installation.
Commercial implementations of X may be shipped without this library. Or have this library broken. Or have XKB implementation which does not use this library. All these scenarios create a lot of troubles for "bad" (from X Window architecture POV) applications using it. The authors of these applications usually realize this fact - but they have no choice (the only alternative for them is some kind of functional regression).
In the long run, the applications will use new version of XKB protocol which would provide network-transparent solution. But for the "old" servers, they'd have to link to libxkbfile for many years to come.
This library was created in attempt to generalize (and make environment-independent) the code dealing with XKB, from the GNOME keyboard indicator applet. It contains a lot of utility code for accessing the keyboard configuration in terms of RMLVO, tracking the keyboard state etc. Its purpose is to provide a foundation for applications like keyboard layout indicators and monitors, keyboard configurators, layout-aware window managers etc.
Initially the library depended on X Window and libxml2 APIs only. Later (during the GNOME 2.15 release cycle), it was ported to gobject-based architecture.
Currently, it is used in production in GNOME only - but it is also used in ongoing KDE4 development (as optional dependency).
The library uses libxkbfile internally, it also accesses keyboard configuration registry file locally. This makes applications using it "bad citizens" in X Window world (there is standing bug report in GNOME bugzilla). Once new version of XKB is provided, the network transparency is going to be restored (for conformant X servers).
The compatibility with original X Window keyboard handling ("xmodmap") is maintained but with low priority.
The internal GNOME library emerged from two virtual modules in GNOME CVS: libgswitchit and libkbdraw. The merger was performed during 2.17 development cycle, the original modules were immediately declared deprecated. The library contains GNOME code related to the keyboard: keyboard indicator widget (including plugin management), keyboard drawing widget, saving/loading configuration to GConf etc.
I'm new to the community and, as all newbies, I'm seeking answers ;-)
My biggest problem after migration from Windpws to Linux was the keyboard in GTK-based GUI applications (Eclipse, Firefox). The problems is that while in non-latin group (for me it's 'ru'), key combinations with CTRL and ALT do not work correctly. I get CTRL+Я instead of CTRL+Z ...
Some people on the net say it's a bug in GTK, some say it's a trouble of each of the GTK-based applications. All I know it that it renders those applications barely useful!
I was wondering if there exists a pure XKB solution? The basic idea is to use latin letter if Control or Alt (Mod1) are present. What about xmodmap?
Hello! I heard it is possible to configure xkb to serve keyboard layout for each application, so for example i can type in russian in browser and keep typing in english in xterm without switching between locales each time i switch to another window.