GNOME Bugzilla – Bug 686984
Activities Overview drag and drop
Last modified: 2021-07-05 14:25:18 UTC
We have a few related bugs in relation to drag and drop in the Activities Overview: 1. If you drag a launcher from the applications view, the view switches to the window selector. This makes it impossible to cancel the drag action - this is a red flag in usability. There should always be an escape route. It is also bad because the view change will be a total surprise. 2. There's a lack of discoverability for drag actions, partly because there is an almost infinite number of choices for where to drag a launcher or a window. If a launcher is dragged from the dash, there is little immediate feedback as to what you can do with it. The same is true if you drag a window. 3. Some drag actions require moving an item over the whole width of the screen (dash to workspace switcher is the worse offender here). There are a few bugs that address point 2, including bug 686982, but they don't actually fix the problem. The answer to these issues is to have a more limited set of actions for each type of drag action, and to update the view to suggest what they are. This would also enable us to have a clearer mental model for how the overview operates. Specifically, this means: a) Window view: only allow dragging windows to the workspace switcher b) App view: only allow dragging launchers to the dash c) Dash: only allow dragging launchers to other locations within the dash (including the grid button) d) Search results: only allow dragging app launchers to the dash. Other types of results shouldn't be draggable For each type of operation, update the view as follows: a) Window view: when a window is dragged, fade out the dash and extend the workspace switcher (if it isn't already) b) App view: only show half the dash [1]. When a launcher drag is initiated, slide out the dash, don't switch to the window view and fade out the other app launchers c) Dash: when a drag is initiated, fade out the window thumbnails or the launchers in the app view (depending on what's visible), and fade out the workspace switcher d) Search results: the dash and workspace switcher should be fully retracted [2]. When a launcher drag is initiated, the dash should extend and the other search results should be faded out. This approach would remove a few affordances provided by launcher drag and drop. Specifically: * Drag a launcher to launch a new instance * Drag a launcher to launch on a specific workspace There is already an alternative to the first of these - Ctrl+Click. I'm not convinced that the second is great behaviour, since you have to drag such a long way. We should try to find an alternative to this though - perhaps we could use the launcher's context menu? [1] http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/overview-application-picker.png [2] http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/search-results.png
(In reply to comment #0) > This approach would remove a few affordances provided by launcher drag and > drop. Specifically: > > * Drag a launcher to launch a new instance > * Drag a launcher to launch on a specific workspace > > There is already an alternative to the first of these - Ctrl+Click. Which exits the overview. > I'm not > convinced that the second is great behaviour, since you have to drag such a > long way. We should try to find an alternative to this though - perhaps we > could use the launcher's context menu? I'm not comfortable doing this until we find a proper replacement. I'd gladly take dragging a few meters to drop over a large target over having to right-click and find the correct fiddly workspace item.
*** Bug 636122 has been marked as a duplicate of this bug. ***
Another note: I don't think that we should change the view after a drag has been completed. Right now, if you drag a launcher to the dash, we switch to the window view - this clearly interferes with adding more than one launcher at a time, and it adds to the unpredictability of the experience.
(In reply to comment #3) > Another note: I don't think that we should change the view after a drag has > been completed. Right now, if you drag a launcher to the dash, we switch to the > window view - this clearly interferes with adding more than one launcher at a > time, and it adds to the unpredictability of the experience. I agree™
(In reply to comment #1) > (In reply to comment #0) > > This approach would remove a few affordances provided by launcher drag and > > drop. Specifically: > > > > * Drag a launcher to launch a new instance > > * Drag a launcher to launch on a specific workspace > > > > There is already an alternative to the first of these - Ctrl+Click. > > Which exits the overview. > > > I'm not > > convinced that the second is great behaviour, since you have to drag such a > > long way. We should try to find an alternative to this though - perhaps we > > could use the launcher's context menu? > > I'm not comfortable doing this until we find a proper replacement. Honestly, I think that fixing this bug is more important than maintaining the existing drag to launch functionality. > I'd gladly > take dragging a few meters to drop over a large target over having to > right-click and find the correct fiddly workspace item. How about we adjust the Ctrl modifier behaviour, so that it keeps you in the overview after clicking on a launcher? That way, you could use Ctrl to launch multiple apps at the same time and you could also open extra windows for already running apps. Additionally, staying in the overview would make it easy to drag new windows to workspaces.
(In reply to comment #5) > Honestly, I think that fixing this bug is more important than maintaining the > existing drag to launch functionality. I don't care about the drag / drop metaphor in particular, but some way to launch multiple applications without exiting the overview each time. Right now, starting up my computer, I have to go into the overview five to launch all the apps I use throughout my day (Firefox, Terminal, Emacs, Empathy, XChat). It's the animations going into the overview that bother me more than anything, to be honest. So I drag out a few terminals to the large space in the middle. > How about we adjust the Ctrl modifier behaviour, so that it keeps you in the > overview after clicking on a launcher? That way, you could use Ctrl to launch > multiple apps at the same time and you could also open extra windows for > already running apps. Additionally, staying in the overview would make it easy > to drag new windows to workspaces. The issue I have with this, as described above, is with launching multiple apps into the same workspace.
(In reply to comment #6) > > How about we adjust the Ctrl modifier behaviour, so that it keeps you in the > > overview after clicking on a launcher? That way, you could use Ctrl to launch > > multiple apps at the same time and you could also open extra windows for > > already running apps. Additionally, staying in the overview would make it easy > > to drag new windows to workspaces. > > The issue I have with this, as described above, is with launching multiple apps > into the same workspace. Which is addressed by my idea - holding ctrl while launching would keep the overview open.
(In reply to comment #7) > Which is addressed by my idea - holding ctrl while launching would keep the > overview open. But that would put it on a new workspace, instead of the same one.
(In reply to comment #8) > (In reply to comment #7) > > Which is addressed by my idea - holding ctrl while launching would keep the > > overview open. > > But that would put it on a new workspace, instead of the same one. No, you thinking of middle-click.
*are*
Ah, OK, that makes sense. Fine by me.
Created attachment 228654 [details] Overview never exits on DND mockup. How about improving DND? We can make Application overview not so anoying shoving it permanently, put Workspaces on the right instead of categories to drag there. Left click function remain the same. So we can switch current workspace / go to another workspace directly from application overview. And new 3.8 "mouse hover on dash opacify windows on workspaces" will work too here.
(In reply to comment #0) > We have a few related bugs in relation to drag and drop in the Activities > Overview: > > 1. If you drag a launcher from the applications view, the view switches to the > window selector. This makes it impossible to cancel the drag action - this is a > red flag in usability. There should always be an escape route. It is also bad > because the view change will be a total surprise. You can press Esc, > > The answer to these issues is to have a more limited set of actions for each > type of drag action, and to update the view to suggest what they are. This > would also enable us to have a clearer mental model for how the overview > operates. Specifically, this means: > > a) Window view: only allow dragging windows to the workspace switcher > b) App view: only allow dragging launchers to the dash > c) Dash: only allow dragging launchers to other locations within the dash > (including the grid button) > d) Search results: only allow dragging app launchers to the dash. Other types > of results shouldn't be draggable > This only makes stuff more confusion as the DND actions will depend on the current context (i.e "I am allowed to do foo in that conext?") ... and "c)" is a no go. This kills a very useful feature for little to no gain.
(In reply to comment #13) > (In reply to comment #0) > > We have a few related bugs in relation to drag and drop in the Activities > > Overview: > > > > 1. If you drag a launcher from the applications view, the view switches to the > > window selector. This makes it impossible to cancel the drag action - this is a > > red flag in usability. There should always be an escape route. It is also bad > > because the view change will be a total surprise. > > You can press Esc, Doesn't help all that much. And we do need a real fix for this issue - it's a nasty one. > > The answer to these issues is to have a more limited set of actions for each > > type of drag action, and to update the view to suggest what they are. This > > would also enable us to have a clearer mental model for how the overview > > operates. Specifically, this means: > > > > a) Window view: only allow dragging windows to the workspace switcher > > b) App view: only allow dragging launchers to the dash > > c) Dash: only allow dragging launchers to other locations within the dash > > (including the grid button) > > d) Search results: only allow dragging app launchers to the dash. Other types > > of results shouldn't be draggable > > > > This only makes stuff more confusion as the DND actions will depend on the > current context (i.e "I am allowed to do foo in that conext?") I don't follow what you're saying here. This proposal will make drag and drop more predictable rather than less. > ... and "c)" is > a no go. This kills a very useful feature You will still be able to open a window and move it to a specific workspace. > for little to no gain. There's at least one nasty usability bug that this will fix. It will also help to guide users by highlighting the options that are available for each drag action. It'll be a big improvement.
I'm now working on this bug. I hope to have a patchset ready in time for 3.7.90 tonight or tomorrow.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #0) > > > We have a few related bugs in relation to drag and drop in the Activities > > > Overview: > > > > > > 1. If you drag a launcher from the applications view, the view switches to the > > > window selector. This makes it impossible to cancel the drag action - this is a > > > red flag in usability. There should always be an escape route. It is also bad > > > because the view change will be a total surprise. > > > > You can press Esc, > > Doesn't help all that much. And we do need a real fix for this issue - it's a > nasty one. I don't necessarily disagree just your "fix" is has a very high cost. > > > The answer to these issues is to have a more limited set of actions for each > > > type of drag action, and to update the view to suggest what they are. This > > > would also enable us to have a clearer mental model for how the overview > > > operates. Specifically, this means: > > > > > > a) Window view: only allow dragging windows to the workspace switcher > > > b) App view: only allow dragging launchers to the dash > > > c) Dash: only allow dragging launchers to other locations within the dash > > > (including the grid button) > > > d) Search results: only allow dragging app launchers to the dash. Other types > > > of results shouldn't be draggable > > > > > > > This only makes stuff more confusion as the DND actions will depend on the > > current context (i.e "I am allowed to do foo in that conext?") > > I don't follow what you're saying here. This proposal will make drag and drop > more predictable rather than less. I have tryed to explain that on IRC not sure how else I should ... > > ... and "c)" is > > a no go. This kills a very useful feature > > You will still be able to open a window and move it to a specific workspace. Yay for extra steps for no reason ... > > for little to no gain. > > There's at least one nasty usability bug that this will fix. It will also help > to guide users by highlighting the options that are available for each drag > action. It'll be a big improvement. Sorry but other then the "drag cannot be canceled easily" I don't see any real problem here. So no this wont be a big improvement but just fix one minor issue at the price of restricting dnd to be nearly useless.
Created attachment 236537 [details] [review] workspaceThumbnails: don't make window thumbnails in the box DnD sources Right now, windows showing in one workspaces thumbnails box are all DnD sources; change it so the workspace thumbnails box is only a DnD target.
Created attachment 236538 [details] [review] dash: don't react to window drags Instead, make the actor half-opaque in that case.
Created attachment 236539 [details] [review] appDisplay: remove unused parameter to AppWellIcon constructor
Created attachment 236540 [details] [review] appDisplay: make overview drag optional for AppWellIcon We don't want dash icons (which are AppWellIcons) to trigger an overview signal, since they won't be available as drag sources outside of the dash itself.
Created attachment 236541 [details] [review] dash: trigger DnD signals internally for our icons We won't get signals from the overview for DnD of our icons, so connect to those ourselves.
Created attachment 236542 [details] [review] Don't call beginItemDrag() for XDND The dragged actors are not overview items.
Created attachment 236543 [details] [review] workspaces: don't track dragged items from the overview There's no situation where we want to accept an item drop from the AppDisplay page right now.
Created attachment 236544 [details] [review] Clean up shellWorkspaceLaunch The presence of the shellWorkspaceLaunch method is used by workspace.js to select the DnD action - Workspace will allow using its actor as a drop target to trigger a launch of the app there if the method is present. Since shell results are never launched on a workspace, and dash items should never be launched on a workspace, remove the implementation in the former and move the implementation of the latter from AppWellIcon to the only client of AppWellIcon that uses it, i.e. AlphabeticalView.
Created attachment 236545 [details] [review] overviewControls: fade view selector and thumbnails slider on DnD - when an item is dragged from the Dash, fade out workspaceView's active page and the thumbnails slider, which are not a drop target - when an app icon is dragged, hide the workspaceView's active page. Thumbnails can't be visible, as there are no draggable app icons in the Windows page
Created attachment 236546 [details] [review] Rename item-drag signals to app-drag signals Now that this signal is only being emitted when the drag source is an application icon (from the application and search pages), we can give it a more meaningful name.
Review of attachment 236538 [details] [review]: I think this is a good idea regardless of whatever else we decide in this stack / bug. ::: js/ui/overviewControls.js @@ +97,3 @@ this.inDrag = false; + this._isWindowDropTarget = params.isWindowDropTarget; I think this would be better as inheritance, where you override _onWindowDragBegin from the dash actor. @@ +309,2 @@ _init: function(dash) { + this.parent({ slideDirection: SlideDirection.LEFT }); And with the suggested changes, this should be a different commit.
Review of attachment 236542 [details] [review]: Looks good. As for the other ones ... I am still not convinced we should do that. I doesn't solve any real problem (only a minor inconvenience) that is worth dropping drag to launch to for.
Review of attachment 236539 [details] [review]: Yes.
(In reply to comment #16) > Sorry but other then the "drag cannot be canceled easily" It's not just the ability to cancel the drag - it's also the uninvited view change that's wrong. > I don't see any real > problem here. So no this wont be a big improvement but just fix one minor issue > at the price of restricting dnd to be nearly useless. The only way to fix the bug I've described above is to not allow drag to launch from the app launcher grid. Once you've done that, you end up in the situation of having launchers behaving inconsistently - you would be able to drag to launch from the dash but not from the launcher grid. It seems better to have the launchers behave consistently, irrespective of where you drag from. The other thing that this fixes is that, right now, if you drag something there is no hint as to what you can do with it. We can fix that by restricting the options and providing visual hints as to potential drop targets. (And that's what Cosimo's patch set does.) The other thing I consider to be a bug is the drag to launch behaviour itself. It seems wrong to activate a launcher by dragging it. The whole drag and drop metaphor is allusion to movement, not activation. That said, I do recognise that people do use drag to launch at the moment, and that should give us pause for thought. A quick way to launch extra instances with only a pointer device is a nice thing to have. It is also nice being able to launch an application on a specific workspace, although I'm kinda skeptical about that due to the length of the drag that is required. We obviously don't want people to feel crippled by these changes. The proposal I have made to work around this is to have ctrl+click launch a new instance and keep the overview open. This would allow someone to launch a new instance and then drag it to a workspace. It does have a couple of disadvantages though: * it's an extra action to move the window to a different workspace * if you don't want to move the window to a different workspace, it's an extra click or button press to exit the overview * it requires the keyboard For all these disadvantages, the new behaviour does seem much nicer for the primary drag and drop behaviours (add launchers to the dash, moving windows between workspaces). Perhaps one alternative would be to have click and drag to launch, but that's quite a lot of extra complexity...
(In reply to comment #30) > For all these disadvantages, the new behaviour does seem much nicer for the > primary drag and drop behaviours (add launchers to the dash, moving windows > between workspaces). Well there is no disagreement on the window movement part (so lets leave that out for now; it has nothing to do with the launchers). As for the launchers we are optimizing for the wrong case here. Launching apps is an everyday task, moving launchers around is a rare thing (you don't do that daily). So we should not cripple a common use case to fix a minor inconvenience in a less common one. If you want to remove drag to launch because the gesture does not make sense to you fine ... but before we do that we need a replacement for this common case.
(In reply to comment #30) > Once you've done that, you end up in the situation > of having launchers behaving inconsistently - you would be able to drag to > launch from the dash but not from the launcher grid. It seems better to have > the launchers behave consistently, irrespective of where you drag from. Is this inconsistency severe enough though? When in Apps view, there are no workspaces to drag launchers to, so it's only natural that drag to launch is not available there. Having the possibility of drag-to-launch depend on the visibility of a suitable drop target (= workspaces) seems intuitive to me. Accepting this [minor] inconsistency for the time being would allow to fix the "unexpected view change" and "no escape route" major issues while preserving the "drag from dash to workspace to launch there" [major] pattern.
(In reply to comment #30) > (In reply to comment #16) > > Sorry but other then the "drag cannot be canceled easily" > > It's not just the ability to cancel the drag - it's also the uninvited view > change that's wrong. > > > I don't see any real > > problem here. So no this wont be a big improvement but just fix one minor issue > > at the price of restricting dnd to be nearly useless. > > The only way to fix the bug I've described above is to not allow drag to launch > from the app launcher grid. You could slide the workspace thumbnails in from the right without changing the page, which I always thought was the best approach.
Getting these out of the way... Attachment 236539 [details] pushed as 6bb38b8 - appDisplay: remove unused parameter to AppWellIcon constructor Attachment 236542 [details] pushed as eab4c7b - Don't call beginItemDrag() for XDND
Created attachment 236714 [details] [review] dash: don't react to window drags -- Updated to use inheritance.
Created attachment 236715 [details] [review] overviewControls: use Params for SlidingControl constructor
Review of attachment 236714 [details] [review]: Let's remove window dragging from/to the dash. This has never made sense.
Review of attachment 236715 [details] [review]: Yes.
Attachment 236714 [details] pushed as cb7778d - dash: don't react to window drags Attachment 236715 [details] pushed as 21403b1 - overviewControls: use Params for SlidingControl constructor
(In reply to comment #37) > Review of attachment 236714 [details] [review]: > > Let's remove window dragging from/to the dash. This has never made sense. FWIW I also think dragging individual windows as sources from inside the thumbnails preview doesn't make sense (what my first patch removes).
(In reply to comment #40) > (In reply to comment #37) > > Review of attachment 236714 [details] [review] [details]: > > > > Let's remove window dragging from/to the dash. This has never made sense. > > FWIW I also think dragging individual windows as sources from inside the > thumbnails preview doesn't make sense (what my first patch removes). I thought both window clones and window thumbnail clones had a "metaWindow" on them?
(In reply to comment #41) > I thought both window clones and window thumbnail clones had a "metaWindow" on > them? Uh? What does this mean in the context of my previous comment?
(In reply to comment #20) > appDisplay: make overview drag optional for AppWellIcon > > We don't want dash icons (which are AppWellIcons) to trigger an overview > signal, since they won't be available as drag sources outside of the > dash itself. Now that we do not switch to the window picker when starting a drag, I think it does make sense to allow dragging favorites to the app display to remove them from favorites (e.g. the exact opposite of dragging app icons to the dash to make them favorites).
I think this makes a lot of sense and is much more consistent with the direction we are heading in for the app view. I'd like to see it get in. A couple of comments. * When I have workspaces disabled (dynamic off, set to have only 1) dragging the window is a bit weird because it has no place to go. * When I drag a launcher on the dash it was really unclear to me how to remove it from the dash. I had to be told I could drop it on the "more apps" button. Maybe we could have a drop affordance there? In any case these are probably just tweaks and we can go forward.
(In reply to comment #43) > Now that we do not switch to the window picker when starting a drag, I think it > does make sense to allow dragging favorites to the app display to remove them > from favorites (e.g. the exact opposite of dragging app icons to the dash to > make them favorites). Makes sense I guess. The one thing that makes it a little asymmetrical is that currently the app view is not using spatial positioning like the dash is. So there won't be a specific drop target.
(In reply to comment #44) > [...] > > * When I have workspaces disabled (dynamic off, set to have only 1) dragging > the window is a bit weird because it has no place to go. You still want to drag windows between monitors though
I didn't have any others. Anyway something to think about for later I guess.
Created attachment 237011 [details] [review] overviewControls: fade view selector and thumbnails slider on DnD When an item is dragged from a page that is not the windows one, the only possible target is the dash, so fade out the rest. -- This is a minimal patch that alone makes a lot of difference I think, and doesn't change the current behavior.
Created attachment 237050 [details] [review] overview: Keep open when a Control key is held It is useful at times to perform several actions that would usually close the overview (for instance launching an application) at once. Currently we allow this by dragging items to a workspace rather than just clicking it, but it's an odd metaphor with its own set of problems. Introduce an alternative approach (inspired by file selection in file managers) by keeping the overview open if a Control key is held down. For what it's worth, I took part in a discussion on #gnome-design yesterday, where two users stated that ctrl-click was actually something they had tried before to launch multiple applications without leaving the overview, because it appeared logical to them to apply their knowledge of multiple selections (file chooser, manager) to the problem at hand. So here is a simple patch which enables this behavior (not just for clicks on app icons, but as a general feature - stuff like quickly changing the stacking order of windows as an easter egg can come in handy at times).
(In reply to comment #49) > Created an attachment (id=237050) [details] [review] > overview: Keep open when a Control key is held I have tested this while it helps it still feels inconvenient compared to simply drag stuff around (especially in the case where you don't want everything on the same workspace).
(In reply to comment #50) > I have tested this while it helps it still feels inconvenient compared to > simply drag stuff around (especially in the case where you don't want > everything on the same workspace). I don't think they're mutually exclusive. My latest patch here keeps the drag-to-activate behavior while still fading out the views when DnD doesn't apply.
(In reply to comment #51) > (In reply to comment #50) > > > I have tested this while it helps it still feels inconvenient compared to > > simply drag stuff around (especially in the case where you don't want > > everything on the same workspace). > > I don't think they're mutually exclusive. > > My latest patch here keeps the drag-to-activate behavior while still fading out > the views when DnD doesn't apply. 1) My comment was regarding Florian's "keep overview open" patch (as an alternative to drag to launch) ... it seemed not to be a better alternative in my testing (i.e it is worse and very limited) 2) What does "dnd doesn't apply" mean in that context?
(In reply to comment #52) > 2) What does "dnd doesn't apply" mean in that context? Look at the patch, it fades out search results/application views when an overview item is dragged, since those views are not drop targets - it doesn't touch the current behavior.
Review of attachment 237011 [details] [review]: OK this makes sense.
(In reply to comment #51) > I don't think they're mutually exclusive. Not at all, there's no technical reason for this to be a replacement rather than an addition, and I think we should consider it independently from a decision on drag-to-launch. (Personally I do use drag-to-launch quite a lot, and I used to be firmly opposed to removing it. There are valid concerns about the behavior though, so I am reconsidering my position ...)
Review of attachment 237050 [details] [review]: This does indeed make sense on its own.
Comment on attachment 237011 [details] [review] overviewControls: fade view selector and thumbnails slider on DnD Attachment 237011 [details] pushed as 1db6d15 - overviewControls: fade view selector and thumbnails slider on DnD
(In reply to comment #55) > (Personally I do use drag-to-launch quite a lot, and I used to be firmly > opposed to removing it. There are valid concerns about the behavior though, so > I am reconsidering my position ...) Well comment 31 still applies here ... I doubt that you reorder your icons more often then you use drag to launch. Adding inconvenience to a common task to fix a minor issue in a rare case simply does not make any sense to me. (And I can't see how this makes sense to anyone really ...)
(In reply to comment #54) > Review of attachment 237011 [details] [review]: > > OK this makes sense. ... unless we allow dragging to the app view to remove a favorite. Of course Jon's concerns in comment #45 make sense though ...
Comment on attachment 237050 [details] [review] overview: Keep open when a Control key is held Attachment 237050 [details] pushed as df0f03d - overview: Keep open when a Control key is held
(In reply to comment #58) > Well comment 31 still applies here ... I doubt that you reorder your icons more > often then you use drag to launch. Yes, but the following also applies: I use drag-to-launch because I want to launch multiple applications, not because I like dragging.
Perhaps this is simplistic, but can't you not slide the view to the left, and then show the workspaces like you would in the dash view? That will give you a target for the drag without having to change the view. Secondly, it's obvious how to cancel the action. Alternatively, show the workspaces in both view and then it's consistent across all views.
So what are we doing with this one?
*** Bug 704312 has been marked as a duplicate of this bug. ***
*** Bug 721359 has been marked as a duplicate of this bug. ***
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.