On Mon, May 08, 2000 at 10:44:52PM -0500, Jason Kasper wrote:
> bbkeys only exhibits this behavior if you use click-to-focus mode for
> blackbox. I have no idea why--I simply stop getting XEvents in bbkeys
> if the focused window is closed with click-to-focus mode in blackbox....
>
Sheesh, I go on vacation for a few days and at long last some
interesting problems surface with the alpha blackbox! Thank goodness
no one's dealt with them yet -- I would've hated to miss out on
the fun.
Anyway, as much as I would like to encourage people not to use
ClickToFocus, I can't resist a good bug-hunt, and I think I tracked
down the problem. The attached patch should fix the problem, and
also deal with the issue which I think the original code was trying
to address -- namely, when a window dies under ClickToFocus, we'd
like its parent to get the focus.
Please test out the patch if you're feeling adventurous -- it hasn't
caused any problems on my machine, but I haven't had a chance to put
it through much since I only got back from vacation a few hours ago.
A short description of the patch follows (there's also some comments
in the patch itself, if you're curious) :
The problem with the existing code is that the parent of the client
window is blackbox's container window, which dies when the client
window does. So passing the focus to its parent quickly results in no
window having the focus, and thus no key events. The first change deals
with this by making ClickToFocus act like SloppyFocus -- when the window
with focus dies, the root window gets the focus.
As for the possible original intent, the second modification causes
the parent of a transient to receive the focus when a transient with
focus dies. Currently it does this in the destructor of the transient
window, which is probably less than ideal, but I haven't had time to
look through the code and see where it could be done instead.
Anyway, let me know if you try it and it works/has problems.
Jeff Raven
[EMAIL PROTECTED]
diff -ur blackbox-0.60.0/src/Window.cc blackbox-0.60.0-focusfix/src/Window.cc
--- blackbox-0.60.0/src/Window.cc Sun Mar 19 20:05:40 2000
+++ blackbox-0.60.0-focusfix/src/Window.cc Wed May 10 21:05:55 2000
@@ -345,8 +345,16 @@
if (client.window_group)
blackbox->removeGroupSearch(client.window_group);
- if (transient && client.transient_for)
+ if (transient && client.transient_for) {
+ // This should cause a transient's parent to get the focus
+ // now that we're dying... I don't know enough about MWM hints
+ // to tell if we need to check anything more here... code in
+ // other places seems to check focus_mode first.
+ // Jeff Raven
client.transient_for->client.transient = 0;
+ if (!screen->isSloppyFocus())
+ client.transient_for->setInputFocus();
+ }
if (frame.close_button) {
blackbox->removeWindowSearch(frame.close_button);
@@ -1183,9 +1191,16 @@
else {
if (! focused) {
if (focus_mode == F_LocallyActive || focus_mode == F_Passive)
- XSetInputFocus(display, client.window,
- ((screen->isSloppyFocus()) ? RevertToPointerRoot :
- RevertToParent), CurrentTime);
+ // This should fix the problems people have had with
+ // ClickToFocus and window cycling -- the main issue was that
+ // we were ending up in a position where no window had the
+ // input focus, and so no key events were generated. Now the
+ // focus should fall to the root window, and key events will
+ // still be generated. I suspect the else clause here will also
+ // cause the same problems, but I don't know enough about what
+ // focus_mode covers to say for certain.
+ // Jeff Raven
+ XSetInputFocus(display, client.window, RevertToPointerRoot, CurrentTime);
else
XSetInputFocus(display, screen->getRootWindow(),
RevertToNone, CurrentTime);
