GNOME Bugzilla – Bug 109677
Dragging onto button != dragging onto window
Last modified: 2018-01-24 13:21:35 UTC
Dragging an icon/link/whatever onto a window list button should be the same as dragging it into the application window. E.g. if I have GIMP running but minimized, I should be able to drag a PNG file from my desktop onto the window list button and have GIMP raise itself and open the file. Or I should be able drag a link from an open email in Evolution to a broswer button, to open the link in an already-running, presumably non-default browser.
Calum: how in the world can we know on which widget in the window the drop should happen? The drop action can change if it's not the same widget. The best example I have right now is that if I drop an icon on my desktop, it can do many things: * if the drop occurs on the trash, then delete the file * if the drop occurs on a launcher then launch the application with the dropped file * if the drop occurs on a folder, move the file there * if the drop occurs anywhere else, move the file on the desktop
I guess I'd expect dropping any sort of object onto something representing an app to be the same as typing "<app> <object>" on the command line-- which in the two examples I gave might equate to "gimp picture.png"[1], or "opera http://www.thinkgeek.com". Much like opening a file by dropping it onto a .EXE file's icon in Windows, which you've always been able to do... except that in this case, there's already an instance of the app running. So with regard to your example, were the desktop to have an icon in the window list, I would expect dropping an icon onto that to do the same as typing "nautilus <object>" in a terminal... which usually amounts to opening it in a nautilus window (in the case of a folder), or in whatever application handles that file type. Admittedly neither of those would be especially useful though, so perhaps creating a link or a copy of the object on the desktop would be a better action in that case. However, there's no icon representing the whole desktop anyway (except perhaps the "Show Desktop" icon, or the views in the workspace switcher), so luckily we don't have that problem :) I'm sure there would be some situations where the expected behaviour could be undefined or ambiguous-- I suppose you'd need to be able to handle those either by doing nothing, or by doing the least dangerous of the things the action could mean, or by raising the application window and waiting until the user continued dragging the object into an appropriate part of that window. For most cases the behaviour seems pretty clear cut though, to my deranged mind at least... [1] Ok, so it would probably be better if it ran gimp-remote in this case... I guess that's the first flaw in my theory :)
Moving to the right component. Sorry for the spam.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/24.