On Sun, Jul 15, 2001 at 02:56:10PM -0500, xOr wrote:
> I've got a question regarding the Workspace::removeWindow function. Here
> is the important section of the function:
> <code snippage>
>
> My question is: Why is XSetInputFocus called when there is no top window
> left and sloppy focus is off, but not when sloppy focus is on?
>
As I recall the basic reasoning is as follows :
Under sloppy focus, blackbox originally gave the window focus by calling
XSetInputFocus with the argument RevertToPointerRoot... when the focus
window disappears, this causes the input focus to fall to whatever is
under the pointer. So there's no need for an XSetInputFocus call in the
snipped code (if all else fails, the root window gets it).
Under click to focus, we don't want this to happen -- the input focus
should only go where we tell it, not where the pointer happens to be.
So if there is no appropriate window, we have to put the input focus
somewhere ourselves. The root window's no good, since we'll get a
sloppy-focus-like behavior; the only other window available to blackbox
is the toolbar.
> The other reason is that when the toolbar is focused, keyboard
> events are not grabbed. I'm going to try to make the toolbar
> process keyboard events, does anyone know why it doesn't how
> to fix it off the top of their heads?
Err. Not grabbed by what? Blackbox? Or bbkeys? If you mean by
blackbox, that's because the main toolbar window isn't told to
report them when it's created (the subwindows are, though).
Change line 102 of Toolbar.cc from
attrib.event_mask = ButtonPressMask | ButtonReleaseMask |
EnterWindowMask | LeaveWindowMask;
to
attrib.event_mask = ButtonPressMask | ButtonReleaseMask |
EnterWindowMask | LeaveWindowMask |
KeyPressMask;
and the toolbar will get the key grabs too.
Hope that helps,
Jeff Raven
