xkb: Switch delay to a group
halsmit at t-online.de
Thu Feb 4 11:40:50 PST 2010
On Thu, 04 Feb 2010 22:18:23 +0300 Ilya Murav'jov wrote:
> Daniel Stone пишет:
> >>> 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.
> Ok, your variant is better, but still not good one; as far as I
> understand "just clear the 'maybe switch' flag" still needs to go
> through all xkbi->filters vector to find the one with that flag.
> So, if I get some useful patches for the issue I attach them to the bug
> http://bugs.freedesktop.org/show_bug.cgi?id=865, ok?
The initial though was just to keep variables very local. When I think of
alternatives and xkbActions.c I always think how much easier some improvements
would be if some other things were there. Actually, I'm happy with you initial
version. I mean, if Daniel says yes to the location.
More information about the xorg-devel