GNOME Bugzilla – Bug 644853
Remove an icon from the dock while the app is running; result is confusing
Last modified: 2012-03-06 14:20:59 UTC
1. Click on a Favorite icon in the dock (e.g. Nautilus) 2. You get a Nautilus window opened. 3. Bring up the dock. Drag the Nautilus icon to the trash in the dock. 4. You get a message, "Nautilus has been removed from your favorites", but in fact the icon "moves" below the favorites, to the space for the running-but-not-favorite apps. This is confusing, as Nautilus seems not to be removed at all; it just changes position. The dock in MacOS doesn't let you drop a running app in the trash; the dragged icon just snaps back where it came from. We could do that, or show a "can't remove a running app" tooltip or something when the icon hovers the trash (or simply don't show the trash if you drag an icon for an app that is running).
I do not think is a bug. The dash and works as a container dock icons for favorite applications. Also works as a task manager. That's why deleting the dock icon, it still appears if the application is running. At closing, you will remove the icon.
Yeah that's a bug.
One way to approach this would be to not show the trash when dragging a running app. The mode switch kill that is planned [1] would change the logic, however. In this scenario we might want to consider making the 'all apps' button insensitive if you are dragging a running app. So it might be worth waiting until the mode switch kill has been done before tackling this bug. [1] http://jimmac.musichall.cz/log/?p=1181
I have to agree with Miguel Aguilar: Do not get in the way of what a user wants to do. If the user wants to remove a running app from favorites while it is currently running? More power to them. Moving it below the "favorites" icons seems like a logical place for it to go, since that is where non-favorite apps go when running. Telling the user that they cannot do something that they most definitely can? That is bad design. Again, this doesn't seem like a bug to me.
How about a message that says "Removed from Favourites but is still running" or "Will be remove from the dash once the program is closed"?
(In reply to comment #4) > I have to agree with Miguel Aguilar: Do not get in the way of what a user wants > to do. If the user wants to remove a running app from favorites while it is > currently running? More power to them. Moving it below the "favorites" icons > seems like a logical place for it to go, since that is where non-favorite apps > go when running. Telling the user that they cannot do something that they most > definitely can? That is bad design. > > Again, this doesn't seem like a bug to me. Well, users want to do different things. They might want to close the app, for example, and might think that dragging to the trash will accomplish that. Another problem with 'let the user do what they want' is that users only become aware of the options that are available to them through the UI that we present. When an app is running, there is no way to tell whether it is a favourite or not. That means that a user will often not be able to predict that dragging the launcher to the trash will unfavourite it. Honestly, this behaviour is really confusing. Users will try to do one thing and end up with something else, and they won't know what has happened. And there is very little reason for them to want to unfavourite while the app is running anyway - so we'd be keeping confusing behaviour for the sake of functionality that is barely ever used. The more I look at this, the more I like the OS X approach that Federico describes in the original report.
(In reply to comment #6) > (In reply to comment #4) > > I have to agree with Miguel Aguilar: Do not get in the way of what a user wants > > to do. If the user wants to remove a running app from favorites while it is > > currently running? More power to them. Moving it below the "favorites" icons > > seems like a logical place for it to go, since that is where non-favorite apps > > go when running. Telling the user that they cannot do something that they most > > definitely can? That is bad design. > > > > Again, this doesn't seem like a bug to me. > > Well, users want to do different things. They might want to close the app, for > example, and might think that dragging to the trash will accomplish that. > > Another problem with 'let the user do what they want' is that users only become > aware of the options that are available to them through the UI that we present. > When an app is running, there is no way to tell whether it is a favourite or > not. That means that a user will often not be able to predict that dragging the > launcher to the trash will unfavourite it. > > Honestly, this behaviour is really confusing. Users will try to do one thing > and end up with something else, and they won't know what has happened. And > there is very little reason for them to want to unfavourite while the app is > running anyway - so we'd be keeping confusing behaviour for the sake of > functionality that is barely ever used. > > The more I look at this, the more I like the OS X approach that Federico > describes in the original report. Though I'd rather not sound like a Devil's advocate, I personally find I add and remove favourites while running programs, so this might not be as favourable as you say. Informing the user with more intelligent notifications or making favourites more clear (while dragging icons or just persistent), say with a star or highlight, could help. I'm just shooting out ideas. Also you mentioned kill switch earlier, I just wanted to share this modification of that idea, which I saw on planet GNOME a while ago, just in case you missed it. I thought it looked pretty interesting to consider: http://seilo.geekyogre.com/2011/12/gnome-shell-face-lift-extension/
Created attachment 209074 [details] [review] dash: Don't allow to remove running apps from favorites Running apps are always kept in the dash, so removing them from favorites just moves them to the end of the favorites list. This behavior is not immediately obvious, so only show the remove target when dragging a favorites application that is not currently running. I had that patch in my tree for quite some time, but as I had hoped that it would be obsoleted by the mode-switch kill, I ended up not attaching it. This is merely a tweak, so it should be possible to still get it into 3.4 ...
Review of attachment 209074 [details] [review]: This looks good, but what about the 'Remove from Favourites' right-click menu option, do we want to show that for running favorites?
(In reply to comment #9) > This looks good, but what about the 'Remove from Favourites' right-click menu > option, do we want to show that for running favorites? Good question - it doesn't involve a trash-can metaphor, so maybe it's less confusing? Allan?
(In reply to comment #10) > (In reply to comment #9) > > This looks good, but what about the 'Remove from Favourites' right-click menu > > option, do we want to show that for running favorites? > > Good question - it doesn't involve a trash-can metaphor, so maybe it's less > confusing? Allan? The menu item seems fine to me, since it doesn't suggest that the launcher will be removed from the dash.
Comment on attachment 209074 [details] [review] dash: Don't allow to remove running apps from favorites I think this can go in then.
Attachment 209074 [details] pushed as 4ac3526 - dash: Don't allow to remove running apps from favorites I'm assuming that it's a small enough tweak to push without freeze break request (in particular, screenshots are not affected and the remove target looks undocumented (in contrast to the "Remove from Favorites" menu item))