[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC]: Window focus changes

From: Benhur Stein
Subject: Re: [RFC]: Window focus changes
Date: Fri, 31 Oct 2003 11:54:57 -0200

On 2003-10-31 03:28:40 -0200 Adam Fedor <address@hidden> wrote:

Perhaps you can try with --GNU-Debug=NSKeyEvent and we could try to
interpret what is going on with the keysyms.
Found it!

I have the following defaults for the control keys:

address@hidden gui $ defaults read NSGlobalDomain|grep Key
NSGlobalDomain GSFirstControlKey 'Control_L'
NSGlobalDomain GSSecondAlternateKey 'Meta_L'
NSGlobalDomain GSSecondCommandKey 'No Symbol'
NSGlobalDomain GSSecondControlKey 'Control_R'
NSGlobalDomain GSFirstAlternateKey 'Alt_R'
NSGlobalDomain GSFirstCommandKey 'Alt_L'

I don't know why, but Meta_L and Alt_L have the same keyCode (64) making the second alternate key
the same as the first command key.

When a new window is created with Command-N (Alt_L), the new window receives a KeyMapNotify event, where it initializes _command_pressed and _alt_pressed, because it if's are independent. When the key is released, only _command_pressed is reset, because in process_key_event the if's are kept together by else's. This leaves _alt_pressed set and all the strange keys I was seeing.

I didn't change the code, but I think that a test should be done when the defaults are read to see if two commands are mapped to the same keyCode, and unify the treatment, to consider the
keys independently or with a precedence in all cases.

The attached patch contains a small correction on a off-by-one test in a vector.
(all this in XGServerEvent.m)

I can't replicate this, but perhaps I don't understand exactly what you
are doing.
Stupid me, I had only compiled back-xlib, and I was testing back-art!
Now I can't replicate it neither. Sorry.

When the window initially gets the click, it calls
-activateIgnoringOtherApps:, which orders all the windows front and
makes the key window key again (i.e. the previous key window). Then the window that got the click makes itself key. I'm not sure how to solve
that one.
Why not just calling activate.. after setting the window as Key?
The attached patch does that.
The activate.. method is put inside the if (!closed). In which situation would a closed
window receive a mouseDown? And should it activate the app then?



Attachment: back.diff
Description: Binary data

Attachment: gui.diff
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]