Post the fluxbox-1.1.1-r1 upgrade, mouse focus is ignored when switching workspaces, rather the last window that had focus on that workspace is selected for focus - irrespective of where the mouse is and irrespective of the session.screenX.focusLastWindow init setting. In order to focus on the window where the mouse is, one must move the mouse off that window and then back on it. Neither portage version 1.0.0-r2, nor the fluxbox-1.1.1 downloaded and compiled from fluxbox.org display the same bug. Reproducible: Always Steps to Reproduce: 1. Install x11-wm/fluxbox-1.1.1-r1 and set it as your window manager with mouse focus on and session.screenX.focusLastWindow = false. 2. Open a pair of xterms in workspace 1 and a pair of xterms in workspace 2. (in the same position on each workspace). 3. Mouse focus over the first xterm in workspace 1. 4. Move to workspace two and mouse over the second xterm. 5. Shift back to workspace one without moving the mouse. Actual Results: The first xterm will still retain mouse focus despite the mouse being over the second xterm. Expected Results: Focus should be on the second xterm due to the mouse being over it.
The fix is really easy: comment out the epatch line with mousefocus-1.1.1.patch in the ebuild. BTW, this is truly ironic.. This bug seems to be assigned to the very person introducing it in the first place. Just, look in the patch file or read my thoughts on this at http://sourceforge.net/tracker/?func=detail&aid=2827510&group_id=35398&atid=413960 ... Talk about going overboard in fixing a minor bug... (sorry, Jim)
First of all I would like to apologize for your inconvenience, but remind you that this is a volunteer-run organization. Please have some patience. fluxbox-1.1.1-r1 is fluxbox-1.1.1 with a number of patches from the upstream fluxbox.org git tree so it is closer to what fluxbox-1.1.2 will one day be, so the problem is a bit deeper than just commenting out a patch. It will just come back when fluxbox-1.1.2 is out. The next point I'm sorry to make is that I don't think there's any 'focusLastWindow' setting any more in fluxbox. I will do some forensic git searching to try to figure out when this went away, but I don't think it was very recently. The current mouse behaviour is "correct" in that it gives precedence to the last-focused list, and this fixes a number of other subtle bugs in WM behaviour. For example, with the mousefocus patch commented out, try to use the WindowMenu to switch to a different window than the mouse is currently above -> You can't. So the real reason for this bug is that focus-follows-mouse is a tricky and nuanced issue, and there's still no perfect solution. I am planning on spending more time on this issue, but you may have to wait a bit. Until then, feel free to continue using fluxbox-1.1.1 and mask the -r1 version.
> First of all I would like to apologize for your inconvenience, but remind you > that this is a volunteer-run organization. Please have some patience. Understood and appreciated. On the other hand it's hard to argue that 6 months may count as some patience. > fluxbox-1.1.1-r1 is fluxbox-1.1.1 with a number of patches from the upstream > fluxbox.org git tree so it is closer to what fluxbox-1.1.2 will one day be, so > the problem is a bit deeper than just commenting out a patch. It will just > come back when fluxbox-1.1.2 is out. I surely hope that's not the case. I've certainly seen this bug show up in several complaints on sourceforge, including the thread I linked to before. > The next point I'm sorry to make is that I don't think there's any > 'focusLastWindow' setting any more in fluxbox. I will do some forensic git > searching to try to figure out when this went away, but I don't think it was > very recently. I don't think this is relevant at all. I wouldn't waste cycles on this, if I were you. > The current mouse behaviour is "correct" in that it gives precedence to the > last-focused list, and this fixes a number of other subtle bugs in WM > behaviour. For example, with the mousefocus patch commented out, try to use > the WindowMenu to switch to a different window than the mouse is currently > above -> You can't. I've read the description of each patch in this set, and they *all* fix correct/expected/desired behavior to something _pardon the word_ idiotic. MouseFocus (or focus follows mouse, or whatever the current name may be) means/implies that the focus should follow whereever the mouse happens to be pointing. And the example, which apparently caused this whole patchset, sounds like a non-issue to me (although, admittedly, I don't ever use the WindowMenu to switch focus, because on my machine focus follows my mouse; so, I can just hover over the window I want to focus...), but if you want to make it work, why don't you just position the mouse (programatically) right in the middle of that window after you raised/focused it? Why mess up the expected behavior for everyone else, just to fix a minor problem, which BTW goes against the chosen "focus policy"? > So the real reason for this bug is that focus-follows-mouse is a tricky and > nuanced issue, and there's still no perfect solution. Actually... as you'll probably be able to deduce from above, I strongly disagree with this statement. > I am planning on spending more time on this issue, but you may have to wait a > bit. Until then, feel free to continue using fluxbox-1.1.1 and mask the -r1 > version. I'm using -r1 with your mousefocus patch replaced by my mostly unrelated (and much simpler, but actually useful) patch for fixing focus on dialogs/popups, while keeping focusNewWindows = false. --- fluxbox-1.1.1/src/Window.cc +++ fluxbox-1.1.1-NEW/src/Window.cc @@ -3842,6 +3842,7 @@ setMovable(false); break; case WindowState::TYPE_DIALOG: + setFocusNew(true); setTabable(false); break; case WindowState::TYPE_MENU:
(In reply to comment #3) > > First of all I would like to apologize for your inconvenience, but remind you > > that this is a volunteer-run organization. Please have some patience. > > Understood and appreciated. > On the other hand it's hard to argue > that 6 months may count as some patience. And I thank you for your *continued* patience, and reiterate that patience is very important when dealing with volunteers who donate their time for free to help you out. > > It will just > > come back when fluxbox-1.1.2 is out. > > I surely hope that's not the case. > I've certainly seen this bug show up > in several complaints on sourceforge, > including the thread I linked to before. It is indeed the case. The patches that you dislike, and referenced in that thead you linked, are in the main fluxbox git tree's master branch. And I agree with you that the behaviour as-is is different from the old fluxbox behaviour, and in some ways probably a bug, but just undoing these commits to reintroduce the other bug is not a valid solution. We need a fix that addresses both issues. > I've read the description of each patch in this set, > and they *all* fix correct/expected/desired behavior > to something _pardon the word_ idiotic. MouseFocus > (or focus follows mouse, or whatever the current name > may be) means/implies that the focus should follow > whereever the mouse happens to be pointing. I'm not sure why I should pardon the word "idiotic". If you want to be insulting, be insulting. If you want help for free, be respectful. Here's another example of a current (and still working) behaviour that does *not* adhere to the strict focus-follows mouse: alt+tab switching. If we were really 100% strictly following the mouse focus, alt+tab would do nothing. So obviously there are cases when it is "expected" that focus will not follow the mouse: Alt+Tab is one. The ClientMenu is another. In my opinion, moving a window with a keycommand is yet another, though some may disagree with that. This nuanced, complicated, and subjective set of "What should the behaviour be for this case" is why my final solution to this problem will be to make things customizable in a fine-grained way. That way you can have your 'Lower' command switch focus if the mouse ends up on a new window, and I can have it keep the focus on the window I just lowered, regardless of what windows are now uncovered. > And the example, which apparently caused this whole > patchset, sounds like a non-issue to me (although, > admittedly, I don't ever use the WindowMenu to switch > focus, It is an issue for those who use that feature. > because on my machine focus follows my mouse; > so, I can just hover over the window I want to focus...), > but if you want to make it work, why don't you just position > the mouse (programatically) right in the middle of that > window after you raised/focused it? That's an interesting idea, which would work if the window is always raised as as a result of focusing it. It would also be a way to keep very strict focus-follows-mouse and still have alt+tab switching work properly. However, if the focus switches but does *not* raise the window (ie, the window may be only partially exposed), this will not work. /me puts this on his list for "maybe someday" fluxbox features... Auto-mouse-warping > Why mess up the > expected behavior for everyone else, just to fix a minor > problem, which BTW goes against the chosen "focus policy"? That's based on your interpretation of what the "focus policy" means. As I see it, focus-follows-mouse can mean one of 2 things, depending on the interpretation of the user: -> The focus is on the window under the mouse, at all times, regardless of what ever else happens that would normally change window focus. This would mean that alt+tab would not work any more, so this is clearly overly-restrictive. -> Focus changes only when you actively move the pointer onto a different window. This is the current behaviour in the fluxbox-1.1.1-r2 ebuild and the head of the master branch of the fluxbox upstream repository. Again, as you and others have argued (successfully), this is also overly-restrictive, and will change when I have time to fix it. So the real solution is a hybrid of the 2, where you can customize the focus to work the way you want it to work. You want to allow alt+tab to work, it can work. You want switching desktops to focus on the window under the mouse? Or on the last-focused window of that desktop? Either way can work. etc. > > So the real reason for this bug is that focus-follows-mouse is a tricky and > > nuanced issue, and there's still no perfect solution. > > Actually... as you'll probably be able to deduce from > above, I strongly disagree with this statement. I can tell that you disagree with my solution, and I hope you can see from my explanations that this isn't a simple "put it back to how it was" sort of deal. We need a consistent and flexible policy so that every user can get what he or she wants out of fluxbox. I know that's one of the main reasons I started using fluxbox -> The absolute customizability. > > I am planning on spending more time on this issue, but you may have to wait a > > bit. Until then, feel free to continue using fluxbox-1.1.1 and mask the -r1 > > version. > > I'm using -r1 with your mousefocus patch replaced by > my mostly unrelated (and much simpler, but actually > useful) patch for fixing focus on dialogs/popups, > while keeping focusNewWindows = false. I'm glad you have a working workaround, and thank you for sharing it with the other users who may be interested in using that same workaround until a final fix is available for this issue. If you have not done so yet, I'd suggest sending this other patch of yours, or perhaps a variant of it with some way to configure it, to the mailing list for inclusion.
Created attachment 233323 [details, diff] Potential fix (pending upstream acceptance) -> Introduces "StrictMouseFocus" focusmodel Okay, here's something pretty close to what I hope fluxbox upstream will accept as a solution, you can patch your fluxbox-1.1.1-r1 to apply this *after* the 'mousefocus-1.1.1.patch' Once this patch is applied, you will have to go into the configuration menu and choose "Mouse Focus (Strict)" to get the old fluxbox focus-follows-mouse behaviour. Please test this and let me know if it solves your problems. If everything looks good, I'll probably roll this into a fluxbox-1.1.1-r2 ebuild.
Created attachment 233329 [details] Output from failed patch attempt This patch doesn't seem to apply to 1.1.1, unfortunately. The doc/asciidoc directory doesn't seem to exist and the manpage has a different date compared to the one you are patching against. The last chunk in FocusControl.cc also needs some fuzz to apply successfully (which epatch does not apply apparently). It's getting late here for fixing the patch and testing, but I can do that tomorrow, unless you'll have a new patch (saving me some time ;-)).
Created attachment 233331 [details] actual output from original patch Oops... I've started messing with the patch in the meantime, and ended up posting the wrong output. Sorry! Here comes the output from your original patch.
Created attachment 233347 [details, diff] Attempt #2 of the strictmousefocus patch Sorry about that, blindly uploaded a patch and assumed it would work. Totally fail. This one is tested: It applies, compiles, and even works! As before, must be applied after 'mousefocus-1.1.1.patch'
The new patch applies, fluxbox builds fine, and based on my limited tests seems to work as expected (after changing from MouseFocus to StrictMouseFocus, of course).
Thanks for testing! After some deep soul-searching, here's what I have decided to do: I have released fluxbox-1.1.1-r2 with a slightly different patch. It ends up reverting much of what the previous 'mousefocus' patch did, and instead just prevents the specific "ClientMenu" bug I had originally inteded to fix. There is also a new USE flag for 1.1.1-r2: "newmousefocus" If this is enabled, it introduces all the old behaviour plus the new "StrictMouseFocus" patch. This way the behaviour change is opt-in instead of forced on you. (Though it will indeed be forced on your when 1.1.2 is released, which will also include the new 'StrictMouseFocus' model) So for you, who have kindly tested the 'StrictMouseFocus' patch, you will need to adjust your configuration back to "MouseFocus" after you upgrade to fluxbox-1.1.1-r2, unless you enable the 'newmousefocus' USE flag, in which case no config changes are necessary on your part. And of course once fluxbox-1.1.2 is out, you'll probably want to change back to StrictMouseFocus again. Enjoy!
