[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