GNOME Bugzilla – Bug 643081
Allow activating of Activities overview during window drag
Last modified: 2021-07-05 14:11:13 UTC
I would suggest that the Activities overlay mode be accessible during a window drag action. For example: 1. Click-and-drag the title bar of an open web browser window. 2. While still holding the mouse-button, hit the "Windows" button (or whatever it's called) to activate the Activities overview. 3. This would open the Activities overview, but keep the current window in a 'drag' mode as if you had entered the Activities overview mode normally and *then* grabbed that window. This way, you can grab a window, enter the Activities mode, and drop it on a new workspace without having to re-find the window in the Activities overview. This could also be achieved with an all-mouse action by grabbing a window title bar, dragging it to the top left hot-corner to activate the Activities mode. The operation may be a bit advanced, but it allows you to move a window to another workspace by starting with the window itself, rather than jumping out to the Activities overview and *then* selecting the window.
Just tried to do that today. I found it weird that I couldn't open Activities by dragging a window, same as I can when I drag a document.
*** Bug 647110 has been marked as a duplicate of this bug. ***
I've also been fighting with this. By the time I've hit the activities corner (which happens to be on the complete other side of the screen from the workspace list) with the intention of dragging a window to a different workspace, and then visually located the window (which is now 'somewhere else on my screen'), and then dragged and dropped it on the new workspace, a good ten or twelve frustrating seconds has passed. It seems like moving windows between workspaces should be classified as core functionality, and core functionality should be intuitive. I realize a lot of things happen in the background when you hit that hot corner, but I doubt that the window-id changes between display modes, and you can drag-drop windows in either mode. Wouldn't some sort of window-already-being-dragged flag that's passed when you hit that corner with a window in tow fix this?
+1. Note also there is an extension that tries to keep windows in roughly the same location they started in when going to overview.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.