Suppose user has configured a window to keep its focus when a new window is created. The new window will raise possibly covering the focused window even in that case. New window should not cover a focused window, but be opened in background, and the item respective to the new window should e.g. blink on Task list to notify about the new window, instead. Related Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/250101
The window manager manages the stack, tnot the apps and the code does that already. So please provide a more detailed reproducer.
A more detailed reproducer? Suppose user has unchecked "Automatically give focus to newly created windows" in Window manager settings. Then he starts e.g. Mousepad. Mousepad is raised above possible other windows on desktop, but remains unfocused. This does not make sense. See also bug: http://bugzilla.xfce.org/show_bug.cgi?id=4796
Ok I see what you mean, I thought you were talking about focus stealing prevention which acts as you described. "Focus newly created windows" just does what is says, only focus. There's room for improvement, but that's a feature request (which makes perfectly sense, it's just that the option is of seldom use).
Sorry, I don't see the effect of the "focus stealing prevention" setting. Can you point me to some documentation or give an example? Unchecking the "Automatically give focus to newly created windows" setting works as a kind of focus stealing prevention. Anyway, I miss view stealing prevention which would keep current windows visible, if focus of a window is kept.
(In reply to comment #1) > The window manager manages the stack, tnot the apps and the code does that > already. Actually I see effect of "Activate focus stealing prevention" in some cases: e.g. if you open a text file by mousepad from thunar not using a custom command, mousepad window is opened under focused thunar window, if "Activate focus stealing prevention" is checked and "Automatically give focus to newly created windows" is unchecked. But if I open an image by Gimp in the same manner, Gimp is opened on top of thunar. Same thing if I open an ODT file by OpenOffice.org in thunar. Or if I start mousepad from xfce4-terminal.
Focus stealing prevention is a fairly complex process which requires that the launcher, the launchee and the current focused application are compatible with focus prevention and startup notification to work. Basically, a timestamp of the last user action is kept per window (and updated by the application). When launching a new application, the panel will set the timestamp of the user action that triggered the launch (via startup notification), then when the window is mapped, the window manager checks that timestamp against the last user action timestamp of the current focused window and only focus the new window if it's later.
Nota: Running applications from the command line does *not* use startup notification and therefore prevents focus stealing prevention to work.
(In reply to comment #6) > When launching a new application, the panel will set the timestamp of the user Which panel? > action that triggered the launch (via startup notification), then when the > window is mapped, the window manager checks that timestamp against the last > user action timestamp of the current focused window and only focus the new > window if it's later. Focus stealing prevention also seems to prevent a new window from being raised above focused window although its name does not suggest it. And it seems to work only if "Automatically give focus to newly created windows" is unchecked. The technique doesn't seem to be popular among many popular applications. Is it part of some standard that is expected to be implemented in most common applications? Could the window manager be used to offer something similar without all those timestamps et al. by controlling how focus can be given to different application and creating unfocused new windows minimized?
(In reply to comment #5) > Actually I see effect of "Activate focus stealing prevention" in some cases: > e.g. if you open a text file by mousepad from thunar not using a custom > command, mousepad window is opened under focused thunar window, if "Activate > focus stealing prevention" is checked and "Automatically give focus to newly > created windows" is unchecked. For some reason I can not reproduce this anymore. Maybe it has got something to do with the fact that I had two thunar processes running yesterday.
(In reply to comment #8) > > Which panel? The xfce panel, or any launcher that supports startup notification and that sets the timestamp properly. > Focus stealing prevention also seems to prevent a new window from being raised > above focused window although its name does not suggest it. And it seems to > work only if "Automatically give focus to newly created windows" is unchecked. Yes > The technique doesn't seem to be popular among many popular applications. Is it > part of some standard that is expected to be implemented in most common > applications? Yes. But many application do it wrong too. That's especially true for apps that manage several windows from a single process, like Firefox, Thunar, Terminal etc. > Could the window manager be used to offer something similar > without all those timestamps et al. by controlling how focus can be given to > different application and creating unfocused new windows minimized? No, if the standard was not needed, it would not have been invented! All parts are required for the mechanism to work, the launcher, the launchee, the window manager and startup notification (or a proper timestamp for windows that are opened from a running application). (In reply to comment #9) > For some reason I can not reproduce this anymore. Maybe it has got something > to do with the fact that I had two thunar processes running yesterday. Yes, as mentioned above, Thunar uses a single process to manage all the windows and it might not set the timestamp properly (there is another bugzilla open for that IIRC). BTW, I have commited the fix so that unfocused windows are not placed on top of the focused window when "Focus newly created windows" is unset, so closing this bug now.
(In reply to comment #10) > No, if the standard was not needed, it would not have been invented! All parts > are required for the mechanism to work, the launcher, the launchee, the window > manager and startup notification (or a proper timestamp for windows that are > opened from a running application). Can you give a reference of that standard? > BTW, I have commited the fix so that unfocused windows are not placed on top of > the focused window when "Focus newly created windows" is unset, so closing this > bug now. Great :)
(In reply to comment #10) > BTW, I have commited the fix so that unfocused windows are not placed on top of > the focused window when "Focus newly created windows" is unset, so closing this > bug now. I tested this in Xfce 4.6 beta3, and it still does not work for every application. E.g. Thunar raises its preferences dialog, but does not focus it. On the other hand I can't think of why anyone would like to open a preferences dialog and not want to have it risen and focused automatically*. With the same settings, Firefox's preferences dialog is not risen and not focused automatically. What is the difference in launching the preferences dialogs of these two applications? *) See Bug #4796
(In reply to comment #12) > I tested this in Xfce 4.6 beta3, and it still does not work for every > application. E.g. Thunar raises its preferences dialog, but does not focus it. So I don't think this bug is fixed. Anyway as for preferences dialogs, I think the fix is to raise and focus the window, but that may be against "New window focus" setting.
Please do not reopen a bug without a good reason. The window manager will not fix all broken apps out there, the application can raise its window and it can also focus it explicitly. Again, you have 3 bugs opened for the same kind of problems, I think you are misusing bugzilla, this is not a general discussion or support tool.
The original issue of the unfocused window covering the focused one is fixed, so closing.
(In reply to comment #14) > Again, you have 3 bugs opened for the same kind of problems, I think you are > misusing bugzilla, this is not a general discussion or support tool. Sorry, if I could not make bug reports that please you. You are right in that I have reported too many bugs about this; I had not perceived which is controlled by window manager and which is controlled by applications itself. Furthermore, it is unnecessary ask someone to fix bugs relative to a specification that you think is bad. Thus I don't open a bug report about this against Thunar, but I have started a discussion about the specification of new window focus in xfce mailing list.
No worries. Starting the discussion on the mailing list is the right thing to do. Just to clarify, this bug is fixed because the window manager now behaves correctly and do not place the unfocused window above the focused one, but that will not prevent an application from raising itself or even focus itself.
From 4965 - Avoid placing unfocused windows on top of the current focused window when not focusing new windows (Bug #4795). I disagree. Placing new windows on bottom doesn't make any sense. It's just tidious to go to the taskbar and bring them to the front, without having "Automatically give focus to newly created windows" set, i cannot even write an email with icedove without visiting the taskbar. On the other hand there are plenty of cases where it's useful to have the new window on top but without focus. Focus and raising are two different things and shouldn't be coupled.
(In reply to comment #18) > I disagree. Placing new windows on bottom doesn't make any sense. It's just > tidious to go to the taskbar and bring them to the front, without having > "Automatically give focus to newly created windows" set, i cannot even write an > email with icedove without visiting the taskbar. Then just focus newly cretaed window, that's what this option is for. > On the other hand there are plenty of cases where it's useful to have the new > window on top but without focus. > Focus and raising are two different things and shouldn't be coupled. Nope, covering a focused window with an unfocused one is not the correct behaviour so the current implementation is correct, and that is not optional. There is no chance that I'll revert this. Feel free to maintain your own patch if you disagree (the change is trivial)
> Then just focus newly cretaed window, that's what this option is for. Wrong. I want to have FULL control over the focus, since not all programs behave well. And i want i windows which i ordered come on top. This is only possible when the focus and the raise policy can be set independently. > Nope, covering a focused window with an unfocused one is not the correct > behaviour You assume, that the window one looks at (= on top) is the same which one works on (= focus). That assumption is not neccessarily correct, which is the base of the classical "focus follows mouse" behaviour. "Covering" is an elastic terminus. Maximized windows should get focus and do with "focus follows mouse" set, a small confirmation dialog of FF can wait, till i give him the focus. > There is no chance that I'll revert this. Feel free to maintain your own patch > if you disagree (the change is trivial) Since i cannot convince you, i'll use devilspie, allthough i feel, that the raising and focus policy is a windowmanager task. Greetings Guido
Guido, I was told to start a discussion about more flexible focus and raising management in Xfce mailing list (and not to do it in Bugzilla since this is not a discussion forum); there it is: http://foo-projects.org/pipermail/xfce/2009-January/024632.html (no responses so far) As for having to go to task bar, you can press Alt-Tab instead. Placing a new window under the focused one makes sense in that you see the focused window. (That said, sometimes I set "Raise no click" disabled, because e.g. sometimes I want to see some other window as a reference when I type something in one window; usually I have to move the covering window so that I can see what I type in the focused window, then.)
(In reply to comment #19) > Nope, covering a focused window with an unfocused one is not the correct > behaviour so the current implementation is correct, and that is not optional. > There is no chance that I'll revert this. Feel free to maintain your own patch > if you disagree (the change is trivial) If focus follows mouse policy is going to be respected, focus can not be given to newly created windows (in all cases). So the new window focus is not an option in that case. I am not user of focus follows mouse policy and I did not have them on my mind when I reported this bug.
(In reply to comment #22) > If focus follows mouse policy is going to be respected, focus can not be given > to newly created windows (in all cases). Nonsense. A user can choose to give focus to newly created windows even in focus follow mouse, that is what this is optional. > So the new window focus is not an > option in that case. I am not user of focus follows mouse policy and I did not > have them on my mind when I reported this bug. Again, this bug is about "Focused window is covered by a new unfocused window", this has been addressed in beta1, this bug is CLOSED so please STOP hijacking this with any random idea that comes to your mind. Period.
(In reply to comment #23) Please read thread "More flexible new window focus setting would be nice" in the xfce mailing list.
This bug does not depend on 4859 at all.