May I rework XKB ?

[Dirk Wallenstein]

On Friday 20 November 2009 00:06:47 Peter Hutterer wrote:
> On Wed, Nov 18, 2009 at 01:26:10PM +0100, Dirk Wallenstein wrote:
> > But honestly, I think it would be a real improvement if users could
> > define their own keymaps with the full range of tools that XKB
> > provides.
> 
> I skipped the other parts, because your last sentence sums it up perfectly:
> we need better configuration tools. XKB from a users POV suffers more from
> the lack of configuration tools, less so from the protoco/implementation.
> 
> For what you seem to be proposing in this thread, the focus should thus be
> on the client application to enable flexible (and persistent) custom
> configuration. Think of an XKB-aware xmodmap, that will be the core of it.

I don't think a command-line tool can in any form reasonably and
intuitively accomplish that, with all the key types and actions.
That's why I wrote Duttulm (http://sourceforge.net/projects/duttulm/).

It already has some very important features. It is possible to edit an
interactive visual representation of a button device, by which it will
be possible to depict information about a keymap in form of key
colors (key-type dissemination, behaviors, action types). Also,
loading and saving to/from an XML representation is completely
abstracted. The current state is described in this pdf:
http://sourceforge.net/projects/duttulm/files/Duttulm/0.1/Duttulm.Introduction.pdf/download

From now on development can focus on XKB keymap specific parts. I have
already put much thought into how to organize the data and how to
isolate the effects of possible changes to XKB.

> Once that application is working, we can re-visit and see what actual
> deficiencies are in the protocol/implementation. I still think you can
> can get about 80-90% there without having to touch XKB (the protocol)
> itself.

Yes, I thought about providing the hundred or so default actions as a
selection of non-editable actions. The result would be the set of
actions available through xmodmap currently, plus configurable
key-types and behavior. This would be a perfect moment to re-visit
protocol/implementation. I think at that stage it could also serve as
a basis for an open discussion about what should or shouldn't be
possible.

Greetings, Dirk.