XKBCONFIG extension: RFP?

[Sergey Udaltsov]

Hi ppl

Some while ago, I mentioned some requirements to the XKBCONFIG
extension I'd love to get in xorg in order to get rid of the "bad
hack" (c) known as libxklavier (well, at least partially). While my
laptop was away in repair, I had some time to draft (thanks to Nokia
9500 spreadsheet application) the requests I would like to see in the
extension. Here is the PDF with the stuff I got:

http://xlibs.freedesktop.org/xkbdesc/xkbconfig/xkbconfig.pdf

(gnumeric version
http://xlibs.freedesktop.org/xkbdesc/xkbconfig/xkbconfig.gnumeric)

A couple of comments:
1. This is MINIMAL set of requests (and no events included, see
below). Probably, more of them are necessary.
2. Possible atoms for properties:
XKBC_DESCRIPTION (ATOM)
XKBC_SHORT_DESCRIPTION (ATOM)
XKBC_FLAG (PIXMAP)
XKBC_COMBINABLE (BOOL, for layouts determine whether layout can be
combined with other, for option groups - whether several options of
the group can be used together)

So, here are the questions:
1. There are no events included. XKB itself issues configuration
change events (well, low-level from XKBCONFIG - but nevertheless). So,
would it make sense to have own, high-level set of events related to
the change of configuration (and, possibly, change of the
configuration DB??)
2.  This extension allows to extend list properties for
models/layouts/options. Does it make sense? Would it be more
economical to use fixed set instead (fixed fields in the
request/response packets)?
3. Ideas are welcome on how to provide ability to have flags scalable
4. The implemenation (if it ever happens) of the extension would
unevitable introduce dependency on libxml. Is this a problem?
5. Would it make sense to prodivide some HAL (USB?) IDs for the
keyboard models - to ease the keyboard hotplugging? This would require
adding an atom XKBC_HAL_ID - and adding some new "search" request.
6. The structure of the extension is heavily based on RMLVGO approach.
One ruleset, one model, N layouts(variants), M options (from their
respective groups). From my POV, it is flexible enough - but if anyone
thinks it is not, please please tell me why.

So, here it is. I'd appreciate any comments, additions, ideas.
Please don't be too harsh - I am not experienced at all in the design
of X extensions.:)

Cheers,

Sergey

> Hi ppl
>
> Recently, one more time, Alan Coopersmith and me were discussing
> incorrect (by design) way of dealing  with XKB configuration used by
> GNOME. So, after Keith's request on IRC, I am describing the features
> I would need from some imaginary X extension which could make 'broken
> hack' something coherent with the current X architecture.
>
> First, I'll briefly describe the problem in terms of simple use case.
> Desktop user wants to configure the keyboard (through GUI, of course)
> with several important points in mind:
> - to be able to enter international characters (from one or several languages)
> - to use all the keys on his keyboard - even extended, multimedia ones.
> - to be able to fallback to existing system configuration
>
> So, XKB extension can be used to configure the keyboard.
> Unfortunately, XKB API is somewhat weak in this aspect. It provides
> access to low-level components (keycodes, geometry, symbols, types,
> compat - KcGSTC) - but does not say how they can be combined in a
> valid way - which is usually non-trivial task.
> XFree and XOrg provide the configuration method based on keymaps - but
> they are rigid, they cannot be combined with some reasonable semantic.
> Also, there is rule-based high-level approach in terms of
> 'rules/model/layout(variant)/option' (RMLVO) - which gives maximum
> flexibility (especially since XFree 4.3.0 with 'multiple layouts'
> feature) - and semantically protects from dealing with low-level
> configuration components (KcGSTC).
> Unfortinately, RMLVO model is not standartized - neither libs/API it
> is using to configure X server - nor approaches to get the directory
> of available configuration elements.
> So, today, in order to utilize this most flexible approach, two basic
> methods are currently in use:
> - using private library libxkbfile (used in GNOME 2.6 - 2.8)
> - launching X server utilities setxkbmap/xkbcomp (used in GNOME since till 2.4)
> - combination of them (GNOME 2.10)
> The directory of configuration elements is either built-in (GNOME till
> 2.4) or taken, on a file level, from X server (GNOME since 2.6)
> NONE of these methods is architecturally correct, especially in terms
> of the network transparency of X Window (not to mention compatibility
> with X servers shipping without libxkbfile).
> (More discussion is available here:
> http://bugzilla.gnome.org/show_bug.cgi?id=152105, especially see
> comment #13 by Ivan Pascal - and, sure XKB and X.Org docs)
>
> So, IMHO it is required to create some new extension delivering
> necessary functionality:
>
> 1. Ability to set configuration in RMLVO terms.
>
> 2. Ability to get from the server information regarding current
> configuration (in terms of RMLVO). Sure, if server is configured using
> low-level options, it can be indicated by retval or something.
> Currently, this isusually done by analyzing the root window property
> XKB_RULES_NAMES (never standartized, part of the reference implementation).
>
> 3. Ability to list (ids, short and long descriptions):
>  - rules. Within ruleset:
>    - models
>    - layouts
>    - variants (per layout)
>    - options groups
>    - options (per group)
> Currently it is done by reading xorg.xml. It would be correct to
> provide descriptions depending on locale (from env or explicitly
> specified)
>
> 4. Ability to say whether particular layout(variant) can be combined
> with others (for server not supporting multiple layouts, this function
> would return == false)
>
> 5. Probably (especially actual for "bad", non-combinable layouts) -
> ability to list the groups within the layout.
>
> The X11 extension with this functionality would allow to create
> architecturally correct user applications configuring the keyboard in
> RMLVO terms.
>
> So, I would appreciate comments on this idea. Especially I'd be
> grateful to get the critics from Alan.
>
> Cheers,
>
> Sergey