News page for Fluxbox 1.3 mentions:
New focus model 'StrictMouseFocus'. This will affect focus when closing, moving, lowering windows, changing desktops, etc, whereas the 'MouseFocus' model will only change focus when you move the mouse.
I tested it and even searched through the code and it seem like it behaves just like MouseFocus (for now). For details see FocusControl.cc/.hh
Maybe this should be mentioned somewhere.
ok, what is the bug now?
Maybe I'm mistaken. Let me explain the expected behavior of StrictMouseFocus according to description at http://fluxbox.org/news/:
Example:
Place two windows directly above each other (titlebars aligned). Upper window has focus.
Lower the upper window by clicking the middle mouse button on the title bar.
Expected result: Window gets lowered and the newly visible window gets the focus (because mouse cursor resides on it's title bar).
Experienced result:
Window gets lowered but the focus didn't change (original window still has the focus).
for me it works ... http://fluxbox.org/paste/strictmouse.flv
I tested it a little more and if you use the title menu item as shown in video, it really works. If u just click the middle button on the title bar, it doesn't.
Sorry about the misleading title of the bug report. I should have tested it further (and shouldn't expected "grep STRICTMOUSEFOCUS" to show me all affected code paths).
well, i use the menu since my real setting to lower is Mod4 + Click3 (right mouse)... so, you are saying that strictmouse does not work if you click the titlebar? what about workspace changes etc?
I use Mod1 + 1-9 for workspace changes, and it always worked for me even with regular MouseFocus. What changes are expected?
well, without strictmouse it focus the last focused window, even if thats not underneath the mouse. with strictmouse it _should_ focus the window thats currently underneath the mouse and ontop of the layer... thats the plan at least.
Yes. It's working as you described. Starting to see a space for a behavior "somewhere in the middle". The only time I didn't like the original MouseFocus was when lowering some windows ( and then needing to Mod1 - click ,or move the mouse out and into the window to get focus.) But keeping focus on the last focused window in each workspace is actually nice.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
bug is simple: StrictMouseFocus only works with the ClientMenu. hotkeys wont work.
I see this is still open so let me add my 2c worth as it's still bothering me (and at least one other on the lists). I have Alt-Mouse2 and Mod4-Tab bound to 'lower' with StrictMouseFocus on - it fails to switch the focus to the new upper window. If I use the window menu or the Mod4-Tab keystroke, it works fine. Just annoying but it bites me every day. This is on Fedora-19 fluxbox-1.3.5-1.fc19.x86_64
Any hope on this? it's a dealbreaker for me to switch to fluxbox, which is a bummer, I thought I'd finally found a winner!
Just to re-state the problem:
'Lower' works differently with StrictMouseFocus when called by
Alt-Mouse2 (focus stays with the lowered window) than when called by
Client menu or Mod4-Tab (focus goes to the new top window).
I found that I could fix the problem with these settings in .fluxbox/keys:
OnWindow Mod1 Mouse2 :MacroCmd {Lower} {ExecCommand focus-top}
Mod4 Tab :Lower
please check if https://github.com/fluxbox/fluxbox/pull/15 fixes the issue.
This is bug #730 and I'd rather not use the solution in pull 15
@thomas: whats the problem with pull-15?
It depends the NotifyUngrab handling on the focus policy what means that
a) notably the DnD (and also the lowering stuff but that's confined anyway) is only fixed for the strict mouse focus policy (in the DnD case, the mouse is on the new window)
b) it will again raise the firefox issue (firefox still causes this, tested) for the strict mouse focus. I assume this would legally perceived a bug/undesired behavior since the mouse isn't involved in this condition at all - a keyboard driven popup would pass away the focus from its parent, now extrapolate this to moving through a menubar ;-)