GNOME Bugzilla – Bug 133037
Support DND without raising
Last modified: 2018-05-02 13:56:10 UTC
To eventually support raiseless DnD without extra work from toolkit users, a way to determine whether a widget may be a drag source is needed. A flag or a property in GtkWidget would suffice. Used in conjunction with globally active input (see bug #68817 and the rejected patch at bug #64613 ), this will allow the main loop to determine whether a ButtonPress should immediately set focus or defer setting focus until a release or other event. Regarding the rejected patch at #64613 : Note that this will not require translation of the WM_TAKE_FOCUS message into a GdkEvent, but does require a way to really set focus from Gtk+. The existing API, gdk_window_focus() which sends a _NET_ACTIVE_WINDOW message, does not suffice for this. Related Metacity reports are bug #128134 and bug #133034 .
The flag idea doesn't work since some widgets determine if something is a drag source dynamically depending on where in the widget the user clicks. So, whatever is come up with for the WM spec we should to support, but it can't be done without some sort of optional dynamic widget involvement
Ping. I'm just trying to push this up on the TODO list of competent DND people :).
I believe this should be marked WONTFIX (as well as possibly some of the other bugs being tracked from bug 133047). Note that I have marked the related metacity bugs as such. Reasoning for this can be found in bug 128134 comment 9, but a quick summary is that these proposed changes would require modifying all toolkits to work, and a number of the changes are controversial and have essentially 0 chance of being adopted by everyone (Lubos already objected on the KDE side of things, and I'm against the side-effects of these changes too). Rather, I think we should instead use the general approach in bug 154260 (and metacity bug 152952) to get this to work, once I go through and clean those up a bit. Just my $0.02.
This looks like a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=80984 "Develop specification for not raising drag source windows during the drag."
*** Bug 400467 has been marked as a duplicate of this bug. ***
The purpose of the flag would be to either prevent or force lower-level handling of a button press event, depending on the default chosen. It allows or prevents dynamic determination. If the default is that button press on a widget sets focus, then the flag would be used to prevent focus. The widget preventing the default focusing would then be responsible for setting focus itself if the button press in fact should have set focus. If the default is that button press on a widget does not set focus, then the flag would be used to force focus. The widget not setting the flag would then be responsible for setting focus itself if the button press in fact should have set focus. As I recall, Apple's Cocoa defaults to not setting focus, then almost all subclasses override that. That seems backwards to me, but perhaps it makes sense because of how they handle events in general. I'm no longer sufficiently familiar with GObject signal handling to speculate what would be best for Gtk+. If there is a way for a widget's button-press-event signal handler to prevent a superclass handler from setting focus with the event, then there's no need for a flag. I realize that right now no class uses button press events to set input focus; I'm addressing what would follow from changing that, from using the globally active input model on X.
Has this really been an issue for 12 years?
Yes. Longer even, though this report is only 10 years old. The issue goes unnoticed among most people who haven't used Mac OS, because that's the only widely used system that fully supports it. MS Windows only has support in File Explorer. Rather than solving the problems with focus and drag-and-drop, X11 environments and MS Windows have moved away from designs that would rely on or even exploit them and moved to designs, such as fullscreen apps, that avoid the problems. There is some hope that Wayland protocols will get this right, so, even with the X11 solution rejected and MS Windows being hopeless, there's reason to have API support for raiseless DND.
Windows only supports this in Explorer? I'm pretty sure it has to be wider than that (maybe toolkit or something?) since it works fine with the file-list that "Everything" (a file search program) has. Even if that's the case, I'm pretty sure a Nautilus-only implementation would solve the case where it's encountered the most. Actually the fact that GNOME Shell lacks a windows list (to drag stuff through) makes the currect DND issue even more annoying since dragging files through activities feels entirely unintuitive. If Wayland provides hope is there actually any progress on that front through the process of making mutter (or rather the entire shell?) a Wayland compositor?
I don't know about the current Microsoft APIs; as of about 16 months ago, there was no support I could find. As I recall, most applications on MS Windows use a file chooser dialog which embeds File Explorer as a component; the special case code is thus widely used. The hope with Wayland is that developers will not get caught up in the same mistakes which have hobbled X11 desktops for so long. It was last discussed on the mailing list in November 2013, when it was deferred for later. Interest remains low because almost everyone who cares just uses a Mac. As I recall, the relevant part of the Cocoa API is the acceptsFirstMouse method of NSView class instances.
I've found out that using Alt key (only works in gnome 3) or shift or ctrl keys can do the drag and drop as we do in Proprietary Desktops. The bug in Action: https://www.youtube.com/watch?v=Qjd6xoAG36Q here's a workaround using Alt/ctrl/shift key + DnD: https://www.youtube.com/watch?v=cjoCxlXLxc0&feature=youtu.be As it is already possible to do the DnD the proper way albeit using alt/ctrl/shift keys. This bug can be fixed, if we can get the DnD work without using the Alt or ctrl or shift key. Thanks.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
The bug is still there. Please keep it open.
-- 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/gtk/issues/232.