After upgrading to 4.6 all new windows (except wireshark apparently) appear underneath all existing windows. They appear at the "bottom" of the stack of "normal" windows. This occurs on all three of my Gentoo/XFCE-4.6 boxes. It occurs with almost every application regardless of whether it's started directly from a .desktop file, from command line, or via exo-open. The only app I've noticed that starts on top is Wireshark. Although I've been told on the mailing list "it's only broken for you", it's also been reported by several others: http://news.gmane.org/find-root.php?message_id=%3c4A37E889.8020009%40yahoo.de%3e http://news.gmane.org/find-root.php?message_id=%3c20090617210018.GA19267%40enterprise.localdomain%3e http://beesbuzz.biz/blog/e/2009/05/01-ubuntu_904_jaunty_xfce_gripes.php Here's my configuration Window manager: [Style] Theme: Galaxy Title font: Sans Bold 9 Title alignment: Center Button Layout: <greyed-out> [Keyboard] <default settings> [Focus] Focus model: Focus follows mouse Delay before focus: <slider at about 10%> New window focus: <not checked> Raise on focus: <not checked> Delay before raise: <slider at about 15%> Raise on click: <not checked> [Advanced] Snap windows to border: <checked> Snap windows to windows: <not checked> Distance: <slider at 10%> Wrap ... screen edge: <not checked> Wrap ... drag off screen: <checked> Edge resistance: <slider at 10%> Hide content ... resizing: <checked> Hide content ... moving: <checked> Double click action: Maxmimize window Window manager tweaks: [Cycling] Skip windows that have skip properties: <checked> Include hidden windows: <checked> Cycle through all workspaces: <not checked> Draw frame around selected: <checked> [Focus] Active focus stealing prevention: <not checked> Honor standard ICCCM focus hint: <checked> When a window raises itself: Do nothing [Accessibility] Key used to grab and move windows: Alt Raise when any mouse button press: <not checked> Hide frame when maximized: <checked> Restore orig size of maximized when move: <checked> Use edge resistance instead of snapping: <not checked> Notify of urgency/blink: <not checked> Keep urget blinking: <greyed out> [Workspaces] Use mouse wheel to switch: <checked> Remember and recall .. shortcuts: <not checked> Wrap depend on desktop layout: <checked> Wrap when first/last: <checked> [Placement] Minimum size to trigger smart: <slider at 10%> By default, place windows: At the center of the screen [Compositor] Enable display compositing: <not checked> <remaining items all greyed> There is a work-around using devilspie to place new windows in a more sane manner (IOW the same as XFCE did before 4.6): http://news.gmane.org/find-root.php?message_id=%3c4A395B59.6070803%40yahoo.de%3e In order to head off the usual spate of suggestions involving giving new windows focus: we don't want new windows to have focus. We just want them to appear on top of existing windows the way they did pre-4.6. For 20+ years I've run with focus follows mouse, click doesn't raise window, focus doesn't raise window, new windows don't get focus. Though I appreciate the effort to help, I'm not really interested in hearing about "solutions" involving changing those settings in order to make my desktop act more like Microsoft Windows.
Thank you! I just wanted to say thanks to Grant for reporting this. I've been looking all over for it. And, thanks to the Xfce team and Olivier for fixing this in the next release. (I assume a fix is planned because a "target milestone" is set for this bug.) I can't wait. This particular combination of window manager settings is one of the best advantages of Xfce, I think. Please please don't ever change this behavior (no raise on focus + no new window focus).
I guess I'd never realized what a small minority I was in preferring such a configuration. Apparently none of the developers or people who've been using 4.6 for the past year use that configuration -- if they had, they would have known within about 30 seconds that things had gotten broken. ;) I'm probably as guilty as anybody when it comes to forgetting to test use-cases that I don't personally use...
I am having this problem also please fix it. Thanks.
me too. however doesn't look like it's going to be fixed? http://bugzilla.xfce.org/show_bug.cgi?id=4795 can I second a vote for this idea from http://foo-projects.org/pipermail/xfce/2009-February/024786.html """ I would suggest to split the "automatically focus new windows" option: [ ] automatically raise new windows [ ] automatically focus new windows """ and given that "automatically raise new windows" has been the default in every WM since 1990 it should be the default in xfwm too.
As suggested here: http://bugzilla.xfce.org/show_bug.cgi
Sorry, I gave the wrong url, it's http://bugzilla.xfce.org/show_bug.cgi?id=5525
(In reply to comment #4) > me too. > > however doesn't look like it's going to be fixed? > http://bugzilla.xfce.org/show_bug.cgi?id=4795 I'm not sure I conclude that from that discussion, but I'm not sure I can conclude anything at all from reading that. > can I second a vote for this idea from > http://foo-projects.org/pipermail/xfce/2009-February/024786.html > """ > > I would suggest to split the "automatically focus new > windows" option: > > [ ] automatically raise new windows > [ ] automatically focus new windows > """ > > and given that "automatically raise new windows" has been the default in every > WM since 1990 it should be the default in xfwm too. I know. The current behavior seems completely bizarre to me, and I don't understand the justification behind the decision to make all new windows start on the bottom of the stack.
(In reply to comment #0) > There is a work-around using devilspie to place new windows in > a more sane manner (IOW the same as XFCE did before 4.6): > > http://news.gmane.org/find-root.php?message_id=%3c4A395B59.6070803%40yahoo.de%3e The work-around isn't quite 100%. Devilspie doesn't seem to do do the right thing occasionally when a new window appears (though I can't figure out how to make it fail). Devilspie also just "goes away" regularly and has to be re-started every day or two. :/
This a not a bug but a result of a fix for bug #4795. It is also a duplicate of at least bug #4808 and 4965 (and prossibly others) It makes absolutely no sense to put unfocused windows on top of focused window, so the current behavior is the correct expected behavior and there is no need to change that back. I would not recommend using devilspie, it's a hack and a source of race conditions with the window manager. *** This bug has been marked as a duplicate of bug 4808 ***
(In reply to comment #9) > This a not a bug You are wrong. It is a bug. The program doesn't behave the way reasonable users expect it to behave. > but a result of a fix for bug #4795. It is also a duplicate of > at least bug #4808 and 4965 (and prossibly others) Why should I care what it's a result of. The program stopped working. > It makes absolutely no sense to put unfocused windows on top > of focused window, You are wrong. That is exactly the behavior that makes sense. It's how I've configured things to work for the past 20 years. What makes you think you get to tell other people what "makes sense"? > so the current behavior is the correct expected behavior No, it is not the correct expected behavior. The correct expected behavior is the way the XFCE window manager used to behave and the way all other window managers I've used for 20 years behaved. > and there is no need to change that back. IOW, a great big "F%*k You" to existing users who liked the previous behavoir. > I would not recommend using devilspie, it's a hack and a > source of race conditions with the window manager. So your recommendation is what? Use a different window manager? Stop using XFCE completely? You say don't fix the bug because you like the new behavior better and everybody who liked the old way is just wrong and has to change to do things your way? You "don't recommend" the one work-around that does make it work the right way? You seem to expect everybody to change to fit the way you want things to be. It must be nice to be the most important person on earth.
Being aggressive and insulting towards developers in bugzilla will not help your cause, quite the contrary.
(In reply to comment #11) > Being aggressive and insulting towards developers in bugzilla will not help > your cause, quite the contrary. My "cause" has been ruled "wrong", my complaints invalid, and I've been told the way I do things "makes no sense". What is there left to do except express my frustration at having my opionions insulted and an incompatible change forced upon me?
I too am afflicted by this bug. Regardless of whether some feel that this is 'not a bug', changing such basic behavior after many years of doing it in completely the opposite fashion is a huge usability flaw. At the very least, there should be an obvious, easy to access configuration option that allows those who want the old/legacy behavior to turn it back on.
Is a configuration option to "automatically raise new windows" (but not focus unless they're under the mouse) on the roadmap anywhere? Would it be hard to add? If it's not planned, then can you please provide a attachment to this bz (or point to the patch from another bz) that reverts the changes of http://bugzilla.xfce.org/show_bug.cgi?id=4795 ? I seem to recall in one of the many bz's about this issue (which is a hint that the behaviour change is upsetting a lot of users) that you referred to it as a "simple change" so hopefully it's simple for you to point at the patch/commit/git id/whatever and for us profoundly unhappy users to revert. it would be most appreciated. Thanks. BTW, maybe you are interested in scenarios where "automatically raise new windows" is sensible? Probably every netbook and most laptops is the main one - browsers (and other apps) typically run fullscreen, and with current xfwm behaviour each download dialogue, or evince instance, or new window, or ... is always completely hidden behind the browser window. there is no indication anywhere that clicking on a link has done anything at all. this is most frustrating... having windows go (effectively) to /dev/null is most frustrating. this behaviour happens even in the extremely common case of a tiny download dialogue that would not steal focus from anything, but yet it is still placed at the bottom of the stack. The ideal outcome for this problem is a configuration option: [ ] automatically raise new windows [ ] automatically focus new windows but a patch to revert the change would also be acceptable.
I am really against adding yet another option for that, so better agree on a sensitive behaviour. What I have now committed in trunk is to place windows behind the focused one only those which have been prevented focus by the window manager. IE, if focus stealing prevention stop a window from having focus, it will be placed under the focused one. But if you explicitely set now windows not to receive focus, those will be placed on top of the stack as before. I think this should give enough flexibility and the expected behaviour for every focus model.
*** Bug 5614 has been marked as a duplicate of this bug. ***
seems to work well. thanks!!!! :-)
I have a little trouble decrypting what #15 actually says but it sounds like it probably fits the bill. When will this hit the streets? Is there a patch I can pick up and apply to general release 4.6.1 source? I have been putting up with this broken behaviour for too long now and need to get a fix in place. It sounds like quite a simple modification was applied to resolve this and Gentoo makes it nice and easy to add a patch to the build process. Assuming this is what we all have been hollerin' for , thanks very much for the fix.
(In reply to comment #18) > I have a little trouble decrypting what #15 actually says but > it sounds like it probably fits the bill. I couldn't figure it out either. > When will this hit the streets? > > Is there a patch I can pick up and apply to general release > 4.6.1 source? > > I have been putting up with this broken behaviour for too long > now and need to get a fix in place. Here's an ebuild for 4.6.1 with a patch that produces the previous behavior. ftp://ftp.visi.com/users/grante/xfwm4/xfwm4-overlay.tar.bz2 It's not the exact same fix that's been made to the official source. It's just a reversion of the change that broke things in the first place. I'm not sure if in all cases it behaves like the "new" fix, but I know it behaves like xfwm4 always used to. -- Grant
Salutations fellow gentooer! brillant , that is one thorn removed from my side. Many thanks for posting the ebuild, saved me a fair bit of messing around. Now sanity has returned I can get back to doing other things and enjoying xfce as I have for the last few years. if you have not done so already I suggest you post that link on the gentoo forums, I'm sure there's a lot of xfacers on gentoo that would appreciate it. best regards.
> Salutations fellow gentooer! Greetings to you as well! > if you have not done so already I suggest you post that link > on the gentoo forums, I'm sure there's a lot of xfacers on > gentoo that would appreciate it. I've posted it to the gentoo mailing list (it had already been posted to the XFCE mailing list). If you'd like, you're more than welcome to post it to the forum as well. I don't have a forum login -- I find them rather awkward to use and generally stick to newsgroups and mailing lists.
(In reply to comment #15) > IE, if focus stealing prevention stop a window from having focus, it will be > placed under the focused one. And focus stealing prevention does not prevent the new window from receiving focus, if user does not continue to interact with the currently focused window (to update its timestamp) after an order to open the new window is given, right? > But if you explicitely set now windows not to > receive focus, those will be placed on top of the stack as before. How would you make such a setting?
(In reply to comment #15) > What I have now committed in trunk is to place windows behind the focused one > only those which have been prevented focus by the window manager. > > IE, if focus stealing prevention stop a window from having focus, it will be > placed under the focused one. But if you explicitely set now windows not to > receive focus, those will be placed on top of the stack as before. I suppose Mr Fourdan meant that if you set "new window focus" disabled and you open a window that is not caught by focus stealing prevention, the new window is placed on top.
This is reported for Xubuntu linux, too: https://bugs.launchpad.net/xfwm4/+bug/366683
This is fixed in current git HEAD, closing. FYI Fedora has backported the (trivial) fix in 4.6 too.
can the fix of this bug causes bug 6484?