X Window Keyboard and around's Journal
[Most Recent Entries]
[Calendar View]
[Friends]
Below are the 20 most recent journal entries recorded in
X Window Keyboard and around's LiveJournal:
[ << Previous 20 ]
| Wednesday, June 10th, 2009 | 10:10 pm
[duke_igthorn]
 |
| | Friday, October 10th, 2008 | 3:22 pm
[dave_pawson] |
Intro and request for documentation.
New to keyboard wizardry, I've just spent 3 days wondering round the net trying to figure out how my Linux (Fedora core 9) gets from keyboard events to glyphs in emacs. Started when I decided to move to dvorak. I'm in the UK, so I found the us dvorak symbols not quite right. I've figured it out using $setxkbmap dvorak (and changing xkb/symbols/us) Also by modifying /etc/X11/xorg.conf to use the uk keyboard, with the dvorak option (only two changes this time). I'm looking for documentation (high level presently) which takes me from the xorg.conf file through to a set of directories (how are these selected?), to matching files from Section "InputDevice" # keyboard added by rhpxl # DP Oct 08. Changed. added grp:, dvorak layout # SkbModel was "pc105". New one selected from bast.lst Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "microsoft" Option "XkbLayout" "gb,dvorak" Option "XkbOptions" "grp:alt_shift_toggle" EndSection through to file gb, 'variant' (if that's the right word) ? How can I find out what values are 'valid' within an Option? Any documentation appropriate to Fedora / Redhat would be appreciated. Second, I'm using a variant of the microsoft 'natural' keyboard. Marked 'natural ergonomic keyboard 4000' $xkbprint $DISPLAY keyboard.ps Seems not to have this model in it's repertoire. Is there any way I could contribute this? TIA DaveP www.dpawson.co.uk | | Tuesday, September 16th, 2008 | 5:52 pm
[duke_igthorn]
|
| | Friday, September 12th, 2008 | 10:55 am
[duke_igthorn]
|
one more time about RMLVO
There is an interesting blog post once again explaining some details of the XKB internals. It does not go too deep, does not touch "dark corners", but can be a good starting point. Highly recommended. | | Monday, April 21st, 2008 | 12:31 pm
[duke_igthorn]
 |
| | Sunday, April 13th, 2008 | 5:55 am
[ralesk]
 |
Persistent custom layouts
Hi all, So I made a custom layout for Hungarian because I can’t stand the official one — naturally, if I want to see the right flag in KDE (and since it’s not for a new, previously unsupported language), it seems to me that the only way to get it to work is to append it to symbols/hu. Problem: apt-get upgrade has a tendency to overwrite it whenever X11 is updated :P So I was wondering, it would be awesome if people could define symbols in their home (say in ~/.xkb/ or something) — no need for root access, and no need to mess with files installed from the packages. Or is this already possible? I haven’t found anything like it yet. | | Thursday, March 6th, 2008 | 6:40 pm
[thinfox] |
Xkb and Combining Characters
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? Thanks Chris | | Thursday, December 13th, 2007 | 7:13 am
[kean]
 |
Where should I put geometry for IBM ThinkPad Z60m, to geometry/thinkpad or 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). | | Sunday, September 16th, 2007 | 12:18 am
[duke_igthorn]
|
The rules to follow...
These days a lot of people contribute new layouts/variants/models to xkeyboard-config. Usually it is done through the freedesktop.org's bugzilla. Quite often that contributed code requires manual "polishing" which would be unnecessary if authors would follow some simple rules. Till today, they really could not be blamed - because these rules existed only in my head. Now, these rules are published. So do not tell me you were not warned ;) PS I still highly appreciate every contribution to the project. I just would like to make my life a bit easier. Thanks for understanding. | | Saturday, September 15th, 2007 | 6:56 pm
[linx56]
 |
| | Monday, April 9th, 2007 | 6:23 pm
[duke_igthorn]
|
... libwhat?
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. libxkbfileLanguage: C Licence: X11 Bugzilla: Xorg 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. libxklavierLanguage: C Licence: LGPL Bugzilla: none 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. libgnomekbdLanguage: C Licence: LGPL Bugzilla: GNOME 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. | | Saturday, December 9th, 2006 | 1:05 pm
[michaelbaranov] |
XKB and GTK shortcuts
Greetings! 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? Thanks! | | Saturday, August 12th, 2006 | 11:00 pm
[duke_igthorn]
|
| | Saturday, July 8th, 2006 | 1:59 am
[duke_igthorn]
|
| | Thursday, April 27th, 2006 | 10:02 am
[jdevelop] |
setting layout per application
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. | | Sunday, March 5th, 2006 | 3:39 am
[duke_igthorn]
|
| | Sunday, January 29th, 2006 | 7:19 pm
[dottedmag]
 |
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. | 11:13 am
[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? | | Saturday, January 28th, 2006 | 5:38 pm
[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. | 2:14 pm
[duke_igthorn]
|
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. |
[ << Previous 20 ]
|
![[info]](http://l-stat.livejournal.com/img/community.gif){kind=small}
xkbconfig