GNOME Bugzilla – Bug 80984
Develop specification for not raising drag source windows during the drag.
Last modified: 2020-11-07 12:35:24 UTC
as metacity does not respect xmms "always on top", I can't drag mp3 files to xmms if nautilus is maximized.
The necessary fix here is some way to avoid raising applications when they are a drag source. Making some common drag target windows stay-on-top doesn't address the real issue. There is no standard way to avoid raising drag sources, and there's no standard way for an app to ask to be on top, either. So basically there is no bug in metacity, but there is probably a specification that needs to be developed on wm-spec-list and THEN there would be a bug in metacity. ;-) Oh, one simple fix to avoid all this might be to raise on button _release_ instead of click. May get us out of the whole issue. I've been planning to try implementing that. So I'll do that before fooling with specs.
Should we leave this as the enhancement and make the bug against when to raise a 'real' bug and not an enhancement?
*** Bug 92390 has been marked as a duplicate of this bug. ***
I went and checked what Windows does on this, and the behavior there struck me as eminently sensible. Windows raises on mouse down unless the window initiates a mouse grab on mouse down (such as in the case of a drag source), in which case it raises on mouse up. So for example in windows explorer clicking on a file icon will not raise until mouse up, but if you click in an empty area of the window, it will raise on mouse down. This makes dragging work the way you expect it should. In sawfish, dragging works the way it does in metacity right now -- raise on mouse down by default. There is also the capability to raise on click only if the window is focused, and this sort of works if you're using click-to-focus mode but is completely pointless if you're using one of the focus-follows-mouse modes. Also, you have to click twice when you want to both raise and focus if you're in click to focus mode. Probably not what we want. Unfortunately, to implement the windows behavior properly without race conditions we would need a way to ask the window if it was planning on grabbing, but obviously we can't do that in a backwards-compatible way since while new apps could say yes and no, older apps would just be mute on the whole issue. Perhaps we could do something like pass through the click, and set a alarm for something like a quarter second in the future, and when the alarm goes off, see if the window has a mouse grab. If so, don't raise; otherwise raise. On mouse up, raise the window the pointer is currently over if and only if that's the same window that we were over on mouse down. This should work for most scenarios, and the worst that could happen is that in heavy load situations or very slow apps, the window will occasionally be raised when it might have been better not to raise it. No big deal. This is a pretty serious kludge, but it should work and requires no EWMH or application changes. Comments? -Rob
So raise on release, OR after a delay if no grab has kicked in. The only problem is, I don't think there's any way to see if there's an active grab, other than trying to grab ourselves and seeing if it fails... maybe I'm just sleepy. Trying to grab ourselves could be OK though. An X extension is also a possibility if really required. Well, I'm all for trying it out anyway. If we write up the basic code we can then tweak the details and try to get it working. Not sure a grab is always DND; e.g. GTK may grab when you click a button. Though perhaps it's right to not focus then, I don't know. I'm guessing the overall effect would be unpredictability (it would seem kind of random when a raise happened and when not).
see my wm-spec-list post at: http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00001.html
*** Bug 132340 has been marked as a duplicate of this bug. ***
This requires only a policy change, not a new protocol. The policy changes for Metacity and Gtk+ are described in the bugs on which bug #133047 depends.
I don't see how we could get all the semantics that we want without implementing the protocol. We want focus and raise on ButtonPress, except in the case of drag and drop, in which case we want it on BottomRelease, and in all focus modes.
Users of clickless focus have already forgone the benefits of a modern desktop environment. Either raiseless DnD can be seen as one of those benefits, or the policies grudgingly offered in my recent comments on bug #128134 can be used.
See bug 152952.
This seems to be the closest thing to my primary source of annoyance with Metacity. I can't understand why raising windows only on button release instead of button down event would be so bad, and it would solve the "can not drag from a full screen window" problem once and for all. I know the no-options policy, but please, if no decision can be made on this, make an option for it, please.
*** Bug 321183 has been marked as a duplicate of this bug. ***
*** Bug 342803 has been marked as a duplicate of this bug. ***
well maybe something should really be done now.... -> Nautilus demands that you click a window to work with it. That also brings it to the front, which means you can't work with partially hidden windows. For example, you can't drag more than one icon at a time from one window to another if the source window overlaps the target area: you click the icon to start the drag, which brings the source window to the top and hides the place where you want to drag it. This is annoying!
*** Bug 347698 has been marked as a duplicate of this bug. ***
theCore on the #ubuntu-desktop channel on irc told me about an option in metacity's gconf, that makes a window not raise when doing a drag&drop. However, it has the drawback, that in some circumstances, one has to click 2 times on a window to make it raise. To enable the drag&drop without the window raising: gconftool /apps/metacity/general/raise_on_click --set false --type bool To revert it to its original state: gconftool /apps/metacity/general/raise_on_click --set true --type bool Maybe I should point out, that the hint I am giving here applies to metacity in the Ubuntu Edgy Eft distribution. I don't know what will happen if applied in another distribution. Francesco
Francesco: You misunderstand that setting; that is not its purpose. This bug is about not raising windows on click in the client area _only_ when that click starts a drag action. That setting makes clicks in the client area not raise windows at all. (You have to click on the decorations or alt-click on the window to raise it.) That setting is garbage for everyone but a certain subset of unix users (such as me); this bug is about behavior we want for everyone.
Hello Elijah, Thanks for your explanation. Now I think to understand better what is happening. I should have said: "There is an option in gconf, that makes a window not raise when the user clicks in it, unless the click happened in the decoration of the window or unless the user does an alt-click on the window." Side effect: The window does not raise, when the user starts the drag&drop with an item situated in the window. I don't know whether turning of this option has further side effects. At least, this might be a way to have a drag&drop that does not change the order of the windows. In other words, if the startpoint and the endpoint of the drag&drop are visible before the drag&drops starts, the user knows that they will remain visible during the whole drag&drop operation. Or am getting it wrong? Have a nice day. Francesco
Yes, the raise_on_click option fixes this particular bug as a side-effect while introducing a far nastier bug (for most users, that is); namely not raising windows on normal clicks. It is not a solution to this problem and I don't even consider it a decent workaround. It exists for other reasons (namely people who don't want windows raised with normal clicks).
*** Bug 459098 has been marked as a duplicate of this bug. ***
I just stumbled on the following PowerUser tip: please, have a look at the 6th point of "Dragging and dropping files" section of this page: http://live.gnome.org/DocumentationProject/TipsAndTricks Is this not the behaviour of the drag and drop that we are looking for? Instead of only occurring when the user presses AltGr, it should always occur. Is there perhaps a way to commute behaviours so that - what happens now with AltGr will happen when no modifier is pressed - what happens now when no modifier is pressed will happen when AltGr is pressed Maybe that somebody knows more about it.
(In reply to comment #22) > Is there perhaps a way to commute behaviours so that > - what happens now with AltGr will happen when no modifier is pressed > - what happens now when no modifier is pressed will happen when AltGr is > pressed Sure, we could make windows not raise on click unless they pressed a modifier (e.g. alt). Such an option already exists, in fact. Making it the default would be really bad. Most users expect windows to raise when they click on them _unless_ that click might begin a drag and drop operation. The problem is determining when a click can potentially begin a drag and drop operation, hence this bug. (On a related note, the AltGr/Super-click thing may only work due to a separate bug in metacity; can't remember the number off the top of my head.)
*** Bug 527630 has been marked as a duplicate of this bug. ***
"Most users expect windows to raise when they click". Agreed, but maybe the problem is the definition of clicking: "An instance of pressing down and releasing a button on a pointing device." At the moment, a window raises when pressing the mouse button; not when pressing and releasing it. When keeping the mouse button pressed, the window should not be raised. So pressing and holding the mouse button on a file in an un-raised window should select the file and not raise the window. Dragging the selected file in another window should not raise the initial window. Using the AltGr/Super-click feature/bug does not seem to work anymore (gnome 2.24.1)
In other words, you want all windows to be raised on release rather than on press?
I think so, Thomas. Windows behaves like this, I think also MAC OS X and KDE ..
Mac OS X also behaves like this. Moreover, I don't think that the solution is as simple as raising the window on button release. For example: when dragging an item from a lower window to a window that is partly over the lower window, the lower window should not get raised at all. As kenden already said in comment 25, the item to drag should get selected instead of raising the window.
Comment #4 from Rob Adams describes the behavior on Windows. Is it the same on OS-X, KDE? And using the AltGr/Super-click feature/bug DOES still work, sorry for the mistake; I was using Compiz, not Metacity.
Comment 25 says nothing about raising the window on mouseup, button comment 4 says that in Windows, it raises that window on mouseup. Here is the behavior of Mac OS X: - I open two windows (called A and B) in the Finder (=file manager of Mac OS X) and place them so that window A is partly covered by window B. - dragging a file from window A to window B does not change the order of the windows - dragging a file from window B to window A also does not change the order of the windows So dragging a file from one window to another window does not change the order of the windows, regardless of the initial order of the windows. Consequently, if Windows raises the window on mouseup (i don't know whether it really is the case), Mac OS X does not behave like Windows.
*** Bug 588048 has been marked as a duplicate of this bug. ***
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use metacity and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.