[PATCH 3/3] xkbcomp: Add missing flag support and correct modifier handling of ISOLock

Ran Benita ran234 at gmail.com
Mon Feb 17 11:35:25 PST 2014


On Sat, Feb 15, 2014 at 05:34:16PM +0100, wettstein509 at solnet.ch 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


More information about the xorg-devel mailing list