GNOME Bugzilla – Bug 112308
Raise windows when they are a drag target
Last modified: 2020-11-07 12:36:47 UTC
It would be cool if metacity raised a window when it is the target of a drag after a short delay (sort of like in the window list). This would be useful for instance in the situation when you are draggin and dropping files inbetween folders.
Owen - is this possible to implement in the WM?
I posted a proposal for a WM spec augmentation to include some sort of WM hint mechanism for dealing with drag and drop windows; never received any comments from the list though. Here's the original post: http://mail.gnome.org/archives/wm-spec-list/2003-March/msg00001.html
Your proposal seems unrelated to this bug report... it's about starting drags not about action during drags. The window manager can't raise on hover because the client messages are (at least for GTK+) sent with a 0 event mask, so only the owner window receives them. (Sending them with a non-event mask was causing problems for Qt/metacity actually since the event propagated to the frame, and GTK+ tried to handle it; I think Qt was going to fix their event mask then.) The drop target could raise itself pretty easily; alternatively, I suppose either the drop source or target could set a "I'm currently a drop target" property that the WM could key off of for autoraise.
Need spec extensions or need to move this to gtk then, it sounds like.
hp, at the very least could metacity raise windows when a user drags an item onto the titlebar of a window?
maybe so, but I would think we should just fix this for real somewhere, it should not be that hard.
Need to bring up on wm-spec-list...
This would recreate the problem to be solved by not raising on drag-start - a window could be raised and get in the way of completing the drag.
The _NET_WM_TAKE_ACTIVITY EWMH extension should handle the dont-raise-drag-start windows (see bug 152952 and bug 154260).
*** Bug 139402 has been marked as a duplicate of this bug. ***
*** Bug 143014 has been marked as a duplicate of this bug. ***
Owen: The XDND protocol specifies that the source window (which will receive the EnterNotify events) will need to send XdndEnter (and XdndLeave) events to the destination window. Could Metacity somehow also receive these events and then raise windows (and perhaps also lower to original stacking) at the appropriate time? If not, perhaps we can extend the XDND protocol to have the source window also send a message to the root window for the WM for EnterNotify and LeaveNotify events.
*** Bug 165206 has been marked as a duplicate of this bug. ***
I'm not sure 165206 needs the same workarounds, if I strace metacity while doing a drag and drop I can see it gets a pile of data ... and that stops once the drag is dropped. All you need to do is trigger on when the drag has finished, and do a find_pointer_in_window()->focus(); or whatever. I presume this should just trigger off a generic grab (Ie. clicking a menu, moving the pointer and clicking/pressing ESC). This issue is about doing something while the drag is in process, for focus all you need is to do something when the drag is over.
*** Bug 165762 has been marked as a duplicate of this bug. ***
*** Bug 165771 has been marked as a duplicate of this bug. ***
Bug 128134 is related, is that a dupe?
Both are about Drag-n-drop, but this bug is about what to do with windows when dropping while but 128134 is about what to do with windows when a drag may be starting.
*** Bug 312157 has been marked as a duplicate of this bug. ***
*** Bug 324960 has been marked as a duplicate of this bug. ***
https://launchpad.net/distros/ubuntu/+source/metacity/+bug/29560 asks for this as well.
Daniel: No, that launchpad bug is the same as bug 152952, which is different than this bug.
*** Bug 335046 has been marked as a duplicate of this bug. ***
*** Bug 339653 has been marked as a duplicate of this bug. ***
Created attachment 65102 [details] [review] Metacity patch implementing this, assuming it can receive XdndEnter messages from the app Currently, as Owen mentioned in comment 3, gtk+ sends XdndEnter messages with a mask of 0 so that Metacity will not get them. (See also bug 81543). I'll be opening a gtk+ bug shortly that modifies that. Given what Owen said in comment 3, this may be the wrong way to handle it, but it'll probably get the necessary conversations started. :) Another thing to think about is e.g. if the user presses Esc to cancel the drag operation; in such a case, the window stacking should probably be reverted to the original. This can't be handled without an extra message type of some sort.
*** Bug 343704 has been marked as a duplicate of this bug. ***
*** Bug 315934 has been marked as a duplicate of this bug. ***
sorry for double posting :)
As per bug 112308 comment 2, using XdndEnter messages for this is probably not going to work, so I'm marking as needs work.
*** Bug 521996 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.