jkh@VIOLET.BERKELEY.EDU (Jordan K. Hubbard) (11/25/87)
>The 'default' behavior of keyboard events going to the window containing the >pointer is actually PointerRoot focus. Since the focus hasn't actually >changed when the pointer moves, there are no events. Many thanks for defining PointerRoot focus. I was beginning to suspect something like that from the code, but it's not clear in the manual. I did decide on EnterNotify, it looks do-able. I just need to SelectEvent on the current window tree as well as newly mapped windows. No big deal. As far as the interaction between "titled" windows and autoraise is concerned, I had thought about that. Since it will be possible to have a mixture of titled and untitled windows on the screen, I thought that storing a "Titled" property for titled windows might be a good idea. The property code is rather opaque, however, so I'm not sure if I understand it correctly. Would the context manager be a better choice? What would you suggest? While we're on this topic, I should ask the following questions as well. Wouldn't it be better to put the feature in xterm that highlights the borders (and cursor) on focus into the window manager? It would be nice if all input accepting applications behaved this way, after all. This would work nicely with titled windows too, since I could just highlight the new parent window border (I'm not going to try and mimic the application's border, too difficult). Here's the rub. After all this, should I do an XSendEvent to the application in case it wishes to take action of its own? An example is the cursor in xterm, there's no way the window manager can muck with that (is there?) cleanly. Let me know if this isn't clear, my grammer is especially horrible this week. Oh yeah, what do you mean by: > want EnterNotify on the children). You'll also have to be careful about > the `oscillating menu syndrome' which will occur when you map the uwm > menu. ?? Jordan Hubbard jkh@violet.berkeley.edu