May I rework XKB ?

[Dirk Wallenstein]

On Wednesday 18 November 2009 04:31:48 Peter Hutterer wrote:

> much of what you propose is already there.

Yes, absolutely. The examples were not so much about lacking
functionality but about what should be made available to users more
easily. And they are just very rigid examples to outline the potential
without going into details about level lookup and such.

The messages of mine in this thread actually cover two topics: 
   - reworking parts of XKB to unlock its full potential
   - making the current or the full potential available to the common
     user.

Reworking parts of XKB 
-------------------------
The main topic, besides the client interaction ideas I stated in
another message, are XkbActions. There are some real nice things
possible with actions and some of them are not accessible. Some of
these things, you might be able to do by means of a xkeyboard-config
keymap, but even those would be so much easier to apply when using
direct configuration. I'm talking about enabling a user to apply
user-specific changes, and not about providing millions of people with
keymaps. 
For example the redirect-key-action. Many widget toolkits support
char-wise or word-wise selection and movement through a combination of
Shift/Control and Left/Right. These could be made accessible on the
main keyboard (say through AltGr-U) by simply filling in a
XkbRedirectKeyAction structure and putting it on the corresponding
level. 
Actions can't be simply unlocked, though. There are some things that
should be improved, mainly in xkbAction.c. For example, the
tracking/filtering mechanism could be improved. What happens if single
actions are changed? Should that even be possible? Or should a change
to an action (or maybe any level) set the device into the default
state. Some handlers could be improved and the sync of the keysym and
action table could be watched more closely (if not merged because of
the memory footprint).


Making XKB's potential available to the user
--------------------------------------------
Even such things as changing the key type of a key are not that
easy to accomplish, without editing keymaps by hand. Not to mention
creating your own keytype and accessing it.


> > > 2.Shortcuts abound
> > > ------------------
> > > Press one key and let the whole keyboard produce keysyms that are not
> > > recognized by any application, so that you can be sure, not to interact with
> > > the currently active application in an unwanted manner. This now inactive
> > > keyboard could be set up, to exclusively interact with the desktop environment.
> 
> what is the common use-case for this?
> it seems a bit like a hack around applications that misbehave. also, what
> client would be "the desktop environment"?

I wanted to say that, if you hold that key you can be sure no key
event _reaches_ the application. The client would be the window
manager as a switch for key events.

> what would be the difference to having an additional group that triggers
> only those "shortcut" keysyms (XF86Back, XF86Forward, XF86Whatnot)?

None. The point of this example together with the example 3 is that I
would like to make the functionalities the window managers offer
easily available, say, to the 10 fingered office worker.
shortcuts for switching applications and desktops is just one example. 

I, for example, have a usual western keyboard with this huge space-bar
and the lack of modifiers at the tips of my pointing fingers. Now, with
the need for Shift, Control, Alt and AltGr on each side of the space
bar there's no space left for a group switch and so I have all sorts
of two-modifier-plus-trigger-key shortcuts to use WM functionality. My
next keyboard will be an Asian one, where they have separate keys for
the pointing finger in the lowest row. I would like to enable the
aforementioned office worker (well, I could use that too, then), to
configure these keys as he likes.

The gist is that it should not be necessary to edit keymaps manually,
and accomplish things that are simply not possible by means or
rearranging keysyms.


> > > 4.Configure remote controls
> > > ---------------------------
> > > The usual device selection buttons on a remote control could be used to switch
> > > between key type levels, so that the other keys produce the key events a
> > > particular application takes for the corresponding action. With a simple
> > > configuration file format that could be supported by those applications, and a
> > > mechanism like inotify, configuration changes in the application could be
> > > immediately active in the remote control. The user would at first create a
> > > general configuration for the remote control, and after that, would only need
> > > to associate the device selection buttons with a particular application.
> 
> that can be done right now by changing the keymap according to the
> application?

The device selection buttons would be radio buttons. If there are more
than 4 of those buttons , you would have to use key-type levels in
some form, as the four groups don't suffice. When using levels, all of
the other keys would have the same key type, with as much levels as
device selection buttons. By pressing a device selection button (which
has radio button behavior) one of those levels is selected and the
shortcuts for one particular application are accessible through the
other keys.

In the manual version the user would now walk through the levels and
assign the corresponding application shortcuts to the levels. If there
are shortcuts involving modifiers, this could be accomplished by
redirect-key-actions. 

In the automatic version the user would assign a placeholder to the
whole key(like Mute, Play, Forward), and applications that want to
support that, could translate their shortcut-table into a configuration
file that maps these placeholder to the actual shortcuts. On demand,
or triggered by inotify, these configuration files could then be
translated into an actual keymap and loaded into the device.


> > > 5.Configure a gamepad as a typing device
> > > ----------------------------------------
> > > With 7 independently combinable buttons it would be possible to type all
> > > characters of the English alphabet and punctuation (6 modifiers and a trigger
> > > key), maybe facilitated by an input method.
> 
> could be done already, it's just the code isn't there that does it.
> especially once you involve an input method, that becomes more
> straightforward.

Basically this example is supposed to demonstrate the flexibility of
key-types. I mean, there are 64 levels on each of the 4 groups
possible for each key, so you have the possibility for a wide range of
functionalities, even with a limited count of keys/buttons.

I was once considering another example. Take two mice, a left
handed and a right handed, with 4 independently combinable buttons
each, and let them produce VCK events. Then spread modifiers and group
switches onto the 8 buttons and create a keytype that can produce any
ASCII char with a combination of group and modifier state. Now put
that keytype onto the space bar and optionally wear a helmet.

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.

Greetings, Dirk.