May I rework XKB ?

[Peter Hutterer]

sorry to reply to Justin's email, your first email didn't make it into my
mailbox.

On Tue, Nov 17, 2009 at 12:20:10AM -0800, Justin P. Mattock wrote:
> Dirk Wallenstein wrote:
> > I would like to give some examples of what a fully functional and configurable
> > XKB extension could offer.
> >
[...]
> >
> > 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"?
what would be the difference to having an additional group that triggers
only those "shortcut" keysyms (XF86Back, XF86Forward, XF86Whatnot)?

there has been talk about grab priorities which can address some if not most
of the issues we face with what I think you're trying to do. it's probably
the better way to go.

> > 3.Use a shortcut setup to control the window manager
> > ----------------------------------------------------
> > By using a shortcut setup from example 2 and making it accessible by one of the
> > keys in the lowest keyboard row, it would be possible to configure advanced
> > window manager interaction that would not require leaving the home row.
> > Shortcuts for switching applications, switching desktops, packing windows, and
> > common application shortcuts, would have some considerable clearance. It would
> > be possible to lock these shortcuts onto the main window (say with
> > Shift-Return), and with slightly improved support from the window manager,
> > there would be the chance to move the active window in a mouse-keys like
> > behavior or force a particular geometry onto a window (For example: maximize on
> > the left halve of the screen, halve the screen's width and a quarter of the
> > screen's height in the top right corner, etc).

see above.

> > 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?

> > 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.

reworking XKB is a good thing to do, though much of what you propose is
already there.
 
Cheers,
  Peter