On Sat, Feb 15, 2014 at 05:34:16PM +0100, [email protected] wrote: > > > + {"neither", (XkbSA_LockNoLock | XkbSA_LockNoUnlock)}, > > > > You didn't add it, but I do wonder what "neither" is good for, it > > renders the action rather useless, no? > > I added it for consistency to other actions, but if we stretch our > imagination: Even with "neither", ISOLock transforms Set/Latch actions; > this has no apparent effect, but if another ISOLock comes up later > (without "neither") those transformed actions will not be transformed > once again. So, if one does not like that ISOLock transforms actions of > key presses before the ISOLock, one can neutralise those with a > "neither" ISOLock, and after that type the usual ISOLock. With the help > of a little utility (XRecord/XTest based typing assistance) this might > even be practical. Maybe.
Heh, clever. > > > + case F_Affect: > > > + if (!ExprResolveEnum(value, &rtrn, lockWhich)) > > > + return ReportMismatch(action->type, field, "lock or unlock"); > > > + act->flags &= ~(XkbSA_LockNoLock | XkbSA_LockNoUnlock); > > > > Would you consider adding a CheckAffectField() function, to unify to > > unify the handling of this for all the actions who use it? I think the > > handling is the same, except for ISOLock, where you'd need to set > > act->affect as well. > > It is not so straightforward, as "act" has a different type at each > instance. Well, the function doesn't need to take the action struct, just the type (for the error msg), and the flags are the same. But I wouldn't worry about it. > Andreas _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
