#1012 StrictMouseFocus not implemented yet in 1.3.0?

[fedy]

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.

[Mathias Gumz]

ok, what is the bug now?

[fedy]

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).

[Mathias Gumz]

for me it works ... http://fluxbox.org/paste/strictmouse.flv

[fedy]

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).

[Mathias Gumz]

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?

[fedy]

I use Mod1 + 1-9 for workspace changes, and it always worked for me even with regular MouseFocus. What changes are expected?

[Mathias Gumz]

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.

[fedy]

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.

[Anonymous]

bug is simple: StrictMouseFocus only works with the ClientMenu. hotkeys wont work.

[Bob Hepple]

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

[Christophe Kalt]

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!

[Bob Hepple]

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

[Mathias Gumz]

please check if https://github.com/fluxbox/fluxbox/pull/15 fixes the issue.

[Thomas Luebking]

This is bug #730 and I'd rather not use the solution in pull 15

[Mathias Gumz]

@thomas: whats the problem with pull-15?

[Thomas Luebking]

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 ;-)