After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 643081 - Allow activating of Activities overview during window drag
Allow activating of Activities overview during window drag
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: overview
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 647110 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-23 15:50 UTC by Steven Garrity
Modified: 2021-07-05 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steven Garrity 2011-02-23 15:50:53 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.
Comment 1 David Prieto 2011-04-24 01:40:11 UTC
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.
Comment 2 Colin Walters 2011-04-29 03:28:26 UTC
*** Bug 647110 has been marked as a duplicate of this bug. ***
Comment 3 Maurice Sprague 2011-10-18 23:10:58 UTC
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?
Comment 4 chinasaurli 2011-11-02 23:07:01 UTC
+1.

Note also there is an extension that tries to keep windows in roughly the same location they started in when going to overview.
Comment 5 GNOME Infrastructure Team 2021-07-05 14:11:13 UTC
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.