Paul Harris wrote: > uuh I suppose that is kind of similar, but the end result I got was that > two windows had a "I've got focus" titlebar.
Yes, yes, me too actually. So that is another aspect of this bug. And in my case the 70% window was a xterm, and it had been raised, its titlebar was saying it had the focus (although the other window titlebar too) but if I tried to type something in the xterm it was not possible. The "focus which allows one to type" was still in the window which now was at the bottom. > Maybe add some > debugging/auditing to ensure that no two windows will display a > focused-titlebar at the same time... ie only 1 window on each workspace > should be on the list for a focused-titlebar. > > Call the new audit_focus() function each time you change the focus > list/states, and do an assert if there is a clash. Then I can run > wmaker with ulimit -c and get a core dump for you... I'll compile the > git repo with debugging enabled (you'll need to tell me how - I assume > there is a flag you can set?) > > You can also just send me the git patch to apply to the git repo, rather > than committing through the git repo itself. I appreciate your willingness to help, but I just stated how the bug can be reproduced in the hope that others in the list will be motivated enough to debug this. I can't do much now. Anyway, the bug is out there. I have one more info to provide. I don't have to be fast with the mouse if I Alt+TAB to the 70% window, it gets raised and I keep the Alt key pressed nevertheless. Then with the alt key still pressed I move the mouse cursor to put it over the 70% window and release the alt key. And that is where the bug occurs. You can notice that the xterm is strange, because its titlebar has the focus but its blinking cursor is not in full color, it is only a empty rectangle. The problem seems to be the key event handling at startWindozeCycle() in src/cycling.c That is all I could gather. -- To unsubscribe, send mail to [email protected].
