xkb: Switch delay to a group

[Dirk Wallenstein]

On Thu, 4 Feb 2010 17:20:54 +0000 Daniel Stone wrote:
> Hi,
>
> On Thu, Feb 04, 2010 at 05:24:52PM +0100, Dirk Wallenstein wrote:
> > On Thu, 04 Feb 2010 18:15:00 +0300 Ilya Murav'jov wrote:
> > > Well, I considered to set up another filter via XkbFilterRec and
> > > _XkbApplyFilters() but xkbi->filters is a vector. If one need to cancel
> > > the delay switching then the vector have to be gone all round to
> > > deactivate the filter. I think another flag in xkbi->state is more
> > > natural.
> >
> > That's the wonderful thing about xkbActions.c. The filter system has to
> > be rewritten, too - it needs per-level granularity. Maybe there can be a
> > more general approach towards canceling actions when doing that.
> >
> > But maybe you would want to put the focus on switch-group-on-release
> > first. If want to try it without Press/Release knowledge inside the
> > handler you might want to try to skip the first event. If that works
> > together with an option to select between when to trigger the switch
> > (press/release), that would be an improvement already.
>
> Actually, it's really not that bad.  In the group-switch handler, you
> could just set a flag for 'maybe switch groups when all keys are up'.
> As the handler gets called for all key events, you could then just clear
> the 'maybe switch' flag when another key gets pressed.


I've been thinking about which actions might need canceling apart from
group switch, and I'm not aware of any. So, a special treatment would
probably be alright currently in any case.

There might be some other actions later, if for example you want to
activate an overlay by pressing two of the modifier keys. But then the
special treatment of group switch could be easily integrated into a
general mechanism.

Greetings, Dirk.