[Squeak-VMdev] Re: spontaneous menu change

[Milan Z. <mil...@sy...>]

Ned,

Thanks. It sounds like what you are saying is this: "Caps Lock on" should=20
modify ONLY Keyboard events from keys A-Z. (not 123 Keyboard events.., not=
=20
mouse events).

=46WIW I agree, I confirmed this is the behaviour of following applications:

	Windows: Pbrush, Notepad
	Linux: Gimp, KWrite, others

=46rom the little I can understand, it seems your suggested change would ma=
ke=20
Linux Squeak VM behave in a way consistent with the above apps.

Milan

On November 28, 2004 01:41 pm, Ned Konz wrote:
> On Saturday 27 November 2004 4:21 pm, Doug Way wrote:
> > So, log it in Mantis as a bug.  (I guess I'll log it if no one else
> > already has.)  The fact that the bug doesn't happen on Windows & Mac OS
> > X makes it likely that it's a bug in the Linux VM... perhaps that VM is
> > specifically turning Caps Lock into Shift when it shouldn't, or
> > something.  At least, I assume that other Linux apps do not treat Caps
> > Lock exactly the same as holding down Shift...
>
> I'd say it's a bug too. Using xev, this is what I see coming straight from
> X:
>
> left-button press
> Caps lock Shift state
> 0 0 0
> 0 1 1
> 1 0 2
> 1 1 3
>
> A key
> Caps lock Shift state char
> 0 0 0 a
> 0 1 1 A
> 1 0 2 A
> 1 1 3 a
>
> 1 key
> Caps lock Shift state char
> 0 0 0 1
> 0 1 1 !
> 1 0 2 1
> 1 1 3 !
>
> So we do get a clear distinction between caps lock and shift, and the caps
> lock does indeed only affect letters.
>
> The bug appears to be in platforms/unix/vm-display-X11/sqUnixX11.c where =
we
> see:
>
> static int x2sqModifier(int state)
> {
>   int mods=3D 0;
>   if (optMapIndex || cmdMapIndex)
>     {
>       int shift=3D 1 & ((state >> ShiftMapIndex) ^ (state >> LockMapIndex=
));
>       int ctrl=3D  1 & (state >> ControlMapIndex);
>       int cmd=3D   1 & (state >> cmdMapIndex);
>       int opt=3D   1 & (state >> optMapIndex);
>       mods=3D (shift ? ShiftKeyBit   : 0)
>
>  |   (ctrl  ? CtrlKeyBit    : 0)
>  |   (cmd   ? CommandKeyBit : 0)
>  |   (opt   ? OptionKeyBit  : 0);
>
> etc.
>
> That is, we're always inverting the SHIFT state when we see a Caps Lock.
>
> But then we're calling XLookupString() to process the keystroke events, a=
nd
> it handles the Caps Lock correctly.
>
> So I'd argue that we should just look at the Shift and ignore the CapsLock
> altogether.
>
> That is:
>
>       int shift=3D 1 & (state >> ShiftMapIndex);
>
> Any thoughts on this? Would this cause any problems?
>
> Thanks,