GNOME Bugzilla – Bug 312421
metacity does not honor preferences for not autoraise window with focus
Last modified: 2005-10-03 22:13:39 UTC
Please describe the problem: If Window Selection under Window Preferences are set to: Select windows when the mouse moves over them (selected) Raise selected windows after an interval (unselected) A window should not automatically be raised when the mouse is moved over it. Steps to reproduce: 1. Set preferences to select windows when the mouse moves over them 2. unselect raise selected windows after an interval 3. Move the mouse over several windows Actual results: Each window will be automatically raised as the mouse is moved over them. Expected results: The window should only be raised when the mouse is clicked on the window. Does this happen every time? Yes. Other information: In version 2.10.1, line 1642 contains: if (TRUE /* meta_prefs_get_focus_mode () == ETA_FOCUS_MODE_CLICK */) If this line were to be changed to if (meta_prefs_get_focus_mode () == ETA_FOCUS_MODE_CLICK) This would honor the preference.
What distro? What patches did the distro or you apply? Did you actually change the line in question? I'm assuming the line you are referring to is from display.c, which is about something unrelated, actually. (Changing that line would result in windows not raising when they were clicked on). What's the output of 'gconftool-2 -R /apps/metacity/general'?
Freebsd 5.4, the port's Makefile says 2.10.1. You're right, changing that line changes the behaviour so that the window is only raised when the edge or title bar of a window is clicked. That is the behaviour I was expecting, as this is the behaviour I experience with openwin or fvwm.
In your original comment, you claimed that windows would raise automatically when the mouse moved over them (i.e. you did not have to click on the windows anywhere, not even the titlebar or edge to have them raise). And you claimed it did this when you had auto_raise turned off. Now, you claim that if you change that line of code that windows do not raise unless you click on the window borders, which implies that windows are not raising when you move the mouse into them after all. I understand that auto_raise is confusing (it's "auto-raise-following-timeout-triggered-by-nongrabbed-mouse-entry" as opposed to "auto-raise-on-click" or "auto-raise-when-doing-dnd-into-new-window", which are totally different), but you appear to have made contradictory claims (perhaps due to the confusion). Could you straighten me out?
I am sorry, the original comment was incorrect. I had made the change listed in my original comment several months ago, and only recently came to the conclusion that the metacity maintainers would not change the default behavior without a bugzilla request, so I did not remember the default behaviour of metacity. My issue is really that when auto_raise is not selected, metacity will raise the active window anyway when there is a keyboard event. With other X window managers (e.g., openwin and fvwm) I have used, if auto_raise is turned off, the window is only raised when the window edge/titlebar is clicked, or a raise_window event (or raise_lower_window event) is received. Since, in my opinion, the whole point of disabling auto_raise is to require the user to explicitly request the window to be raised to the top, the standard metacity behaviour is incorrect. In particular, if I want to have overlapping windows so that I can view an entire window, yet type into a window that is mostly overlapped by the window I want to view, I can do that with openwin or fvwm, but not with the standard metacity (or MS Windows, bleah). So, the original example should be: 1. Select window when mouse is over window, and deselect auto_raise 2. Bring up two windows and have them overlap 3. Type while the mouse is over the lower window. metacity will raise that window to top, which I submit is the wrong behaviour. I hope this clarifies what I am seeing, and why I think the standard behaviour is wrong.
Right, understood now. There were two problems: (1) You totally misunderstood "auto_raise" (as is a common thing to do since its' ambiguous naming could easily refer to _at least_ three different things--and its explanation in the preferences dialog doesn't clear up the ambiguity at all; in fact, the ambiguity has caused problems just like this multiple times before and resulted in me filing bug 154614), (2) You want an orthogonal raise. (2) has been discussed in lots of other bugs, for example bug 86108, bug 115072, bug 115753 (I can point you to various patches though, if you're interested--email me privately). So, I would mark as a duplicate, but I'd like to do at least _something_ to alleviate (1). I'll attach a patch in a minute.
Created attachment 50244 [details] [review] Try to clarify the meaning of auto_raise preference
I committed the patch; the remainder of the bug is a duplicate of others like 86108 as pointed out above, so I'm going to mark as fixed. If someone doesn't like that, then we can reopen and mark as a duplicate...