Random collection of ideas related to XKB2

To editors: Please do not use that list as bugzilla. Think about general changes, not particular bugs. Make sure the functionality you're asking is not possible currently.

Break the limit of maximum number of groups (currently 4). Make it at least 5. (daniels: not a problem, though requires xi2.)
Full support of network-transparent handling for XKB configuration specified as Rules, Models, Layouts, Variants, Options (RMLVO). That includes:

2.1. Enumeration of all available configuration elements, separately R,M,L,V(L),O

2.2. Getting (drums roll...) translated description for configuration element

2.3. Getting (extensible?) meta-info for the configuration element. For models - vendors, for LV - language(s), country(s)

2.4. Setting/getting current XKB configuration

Specifying different action for key press and key release. There is a hack in bugzilla related to the group switching "on release" - that should be generalized.
Standardize at least some option group names - could be useful for GUI. First candidates: grp, lv3, lvl5, compose, perhaps more
Support for scenarios "multiple keypresses - one keysym" and "single keypress - multiple keysyms".
Support for virtual devices (shouldn't need to use XTest for things like x2x/synergy/vnc, and virtual devices would be slicker for virtual-machine interfaces)
XKB config syntax using XML. In particular, use (subset of) SVG for geometries
In the geometry, allow to define an area for label placement for each key. Must be a rectangle, inside or outside the key, as it is on the physical keyboard. Useful for irregular polygons like L-shaped keys. Difficult to calculate for arbitrary polygons, more if they are curved (like if the key has the shape of a U, a moon, an irregular star...) --alvarezp
When turning autorepeat off for an already repeating key, stop repeating it, or have a way to instruct the server to stop repeating keys. --alvarezp

Comments

svu (24.05.2010)

2 - basically putting base.xml on wire.

2.2 - should depend on the client locale. There are various options: client-side translation, server-side translation with explicit locale, server-side translation using some way (XLOCALE extension?) allowing to specify the locale for X session.

2.3 - ISO codes to be used

50 - separate discussion required. Can replace "Compose" functionality, can help various Input Methods

There are also some ideas related to implementation - like dropping binary (xkm) format, using text-only representation.

svu (27.05.2010)

98 (removed) Good support for per-device layout management (Just because 1 keyboard plugged is in dvorak doesn't mean they all are) XKB always supported it. GUI tools usually don't.

100 (removed) Support for pressing the Windows button as well as pressing Windows + L in the same keyboard layout/settings. Currently the Windows key can either be a normal key or a modifier but not both. - related to the fact that you cannot have different actions on press and release. See #3

129 (removed) Allow the enumeration of arbitrary keyboards outside of the current configuration. It is a common mistake on some configurations that no geometry is configured, and the clients can't query XKB for 'pc(pc10[45])' to get a default. --alvarezp - this can be fixed with the existing framework of rules. IIRC if no geometru specified, pc105 is used by default. If it is not - it should be fixed. But there is always possibility to request arbitrary configuration from the server, see ?XkbGetKeyboardByName (and if you want it in terms of RMLVO, see #2).

130 (removed) Explicitly standardize the semantics of "model", particularly to be able to specify an exact model as described by the manufacturer. For example: External keyboards => exact model of the keyboard used to create the record; for laptops => exact model of the keyboard AND exact model of the laptop with original keyboard. For KVMs... --alvarezp - possible within the current framework. Feel free to open a bug, where we can discuss that.

131 (removed) Explicitly standardize that geometries should always include outlines in multiples of two, the base and the top for each step up in the shape, even if they are equal (like in some netbooks), OR that if it is an even number, that the last one should be duplicated. Useful for identifying lateral sides of keys and painting accordingly. --alvarezp - I do not think this is fair requirement. It can be easily done with simple math (CMIIW)

132 (removed) Allow oval shapes, being "circles" a particular case. --alvarezp - The ultimate goal would be to use some subset of SVG for geometry - just incorporate keycodes and indicators into it. #99 updated.

133 - could you please elaborate, what's the current behavior?

daniels (27.5.2010) # #1 Easily done, but requires clients to be using Xi2 as well.

2 No problem, except I'm skeptical of the translation/extensible metadata thing - half the point of this was to remove stuff and make it smaller!

4 I don't think it's reasonable to put this in the spec. xk-c is the de facto standard in this area anyway, though I might cobble together a much more minimal dataset that you could reasonably expect would be present everywhere.

50 Single->multiple is easily doable, but multiple->single is much more delicate (say you have 'o' and '/' generating 'ø', and a grab on '/': what happens when you press '/'?), and I'd rather leave it in the input method for the time being.

97 This is something for Xi rather than XKB, as XKB does not deal with sending events to clients, and any XTest replacement would need pointer motion anyway.

99 NNNNNNNNNNNNNNNNNNNNNNNNNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO. I'd like to kill geom from XKB anyway; if it does exist, I don't think it has any particular business being on the wire. #128 is part of the reason why - it's ungodly complex, and the server has absolutely zero use for it.

alvarezp (2010-05-27)

99 -- I'd like to kill geom from XKB anyway --daniels -- Nonono, no killing. Geometries are central to my application, as it paints the current keyboard on screen whatever it is. #128 is just adding another field to the database, with whatever implications.

129 (removed by svu) this can be fixed with the existing framework of rules. IIRC if no geometru specified, pc105 is used by default. If it is not - it should be fixed. But there is always possibility to request arbitrary configuration from the server, see ?XkbGetKeyboardByName (and if you want it in terms of RMLVO, see #2). -- Thanks, will raise bugs for both, since pc105 is not a default, and ?XkbGetKeyboardByName fails to load geometries outside of current configuration.

130 (removed by svu) possible within the current framework. Feel free to open a bug, where we can discuss that. -- Will be done, thanks.

131 (removed by svu) I do not think this is fair requirement. It can be easily done with simple math (CMIIW) -- Yes, it can be done by making simple assumptions, and that's how I do it, but those assumptions are outside of the specification. That's why I ask.

132 (removed by svu) Allow oval shapes -- The ultimate goal would be to use some subset of SVG for geometry - just incorporate keycodes and indicators into it. #99 updated. -- Sounds really nice. It would just be needed to keep the semantics: bounding box, primary outline, approximation outline, detailed outline, to be able to detect the top of the key and drawing inside it, not just a meaningless shape.

133 - could you please elaborate, what's the current behavior? --svu // http://web.archiveorange.com/archive/v/Ky751V5Yp70TRzlmvsit Daniel says it is not a bug as, according to XKB, actions only affect unpressed keys.

svu (2010-05-31)

400 - Support for applications to request a keyboard with keys xyz and for Xorg to bring up an on-screen keyboard when equivalent hardware keys are not available. Useful on smartphones for example where there may only be a number pad or a couple of buttons and a fold-out keyboard. - Can be implemented externally to the server. Should be implemented externally.

daniels (2010-06-01)

(Much like top-posting, it seems that non-nested comments do not scale.)

99 - Sure, and it's a nice idea, but given how woefully incomplete our geometry database is, and how crap vendors are at actually putting anything useful ever into their HID strings, I don't think it's worth keeping in the server. I've nothing against exposing a model name that tries to be as useful as possible, but geometry is a mess right now, and easily the most fragile part of the extremely fragile keymap handling code. I don't see any benefit to having it on the wire instead of in an external database, particularly if the latter can be useful to others.

129 - Regardless of any of the above, this should definitely be fixed. I saw the bug and will try to get around to it.

131 - This is exactly the kind of thing I'm talking about, BTW ...

svu (2010-06-01)

99 - well, you seen the code, while I did not, so you definitely know better how it all organized. But the thing is that functionally the geometry is nearly transparent meta-info. All server is required to do is parse it and provide it when asked. It could be declared as "anything parseable by clients" (with mime type?) buffer. Actually, that is the reason I proposed SVG - from the server POV, the format of geometries does not really matter, the behavioristic parts of the code do not use geometry info, right?

(Perhaps we really should reorganize the buffer into some threaded form)

daniels (2010-06-10)

99 - How about just using an Xi property containing a boatload of SVG, then? :)

svu (2010-06-16)

99 - That would make sense. Except that we need to settle some convention on using xkb-specific elements (keycodes and stuff) within SVG. Otherwise I am happy with it.

Daniel, with this approach, do you see that in a future existing XKB would be implemented as compatibility layer over allmighty XInput? Mapping SVG to XKB geometry would be funny:)