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. > > Cheers, > Daniel
Ah, now I know what you meant. The special handling for group-switch can be restricted to XkbHandleActions() because the filters are available there. _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
