Supporting background window actions

It’s long been an issue for GNOME that users cannot drag items from background windows without activating those windows. There was never a consensus reached (within GNOME or among other free software projects) about how such a thing should be done.

Wayland may make this possible.

To that effect, I’ve created an issue for wayland-protocols: xdg-shell: support background window actions (#143) · Issues · wayland / wayland-protocols · GitLab

There’s no discussion there at this time, but I hope that will change.

If background window actions do become possible, an API change may be needed in gtk.

As far as I can tell, gtk on X11 still uses the locally active input model and the current expectation on wayland is no different. What may be needed, in X11 terms, is to change to the globally active input model. This can actually be done without an API change. Because every extant window manager always sends a WM_TAKE_FOCUS message on window clicks in click-to-focus mode, gtk doesn’t need to change at all; it can use the globally active input model by just changing the InputHint to false and doing nothing else.

If things change so that background actions are possible, gtk will need to do a little more work. A button press event will no longer always cause a compositor to activate a window, but the client will need to call for activation if there’s no possible background action to be performed. The simplest change to gtk, requiring no API change at all, is to always request activation in response to a button press event. That’s less than ideal, because background actions will still not be possible, but it’s a step along the way.

For gtk to actually support background actions, there will need to be a way to determine if such an action is possible and act accordingly. I believe, but I’m not sure, that this will require an API change. The API will only matter to people creating widgets that may be drag sources; everything should just work for everyone else. I haven’t been familiar with gtk since version 2.x, but I think all that is needed is a signal for GtkWidget that returns a boolean indicating whether activation should be requested, and defaults to true. Drag sources would just return false if a drag may be starting. I know it’s more involved with that, but I’d be writing patches if I knew what to do right now.

I’m just getting back to looking at free software after a long hiatus, so I’m still getting familiar with both code and customs. I apologize if I’m approaching this the wrong way. I’ve long been bothered by the lack of parity between free software and Apple software when it come to drag-and-drop, and I hope to do something about that.

You have provided a detailed description of your ideas. Nevertheless, I am not sure whether I have understood you right.

Here is a short description of a feature from the user perspective:

  • we have a file manager (FM) in the background and an application window in front of it; the application has focus
  • the user clicks on the file name in the FM; at this moment the application does not disappear behind the FM and is kept visible
  • the user drags the file name to the application window and drops it here
  • the application opens the file (if it can)

This is how it works on Windows. This is one of very few features (I think only two) that I really miss on Linux.

A kind of workaround is to drag the drop cursor to the taskbar and to position it over the icon of the target (= destination) application. After this is done, the application window, which has disappeared after clicking the FM, gets focused again and the rest of the task runs like on Windows.

It seems that it is possible to have a source application in the background, the target application focused and the drop cursor dragging. What if this state would be initiated just after click on the file name in the FM? Is it possible? Probably, this does not need any changes on the system level?

Yes, what you describe on Windows is the kind of interaction I’m talking about. On Mac, you can drag any background selection as well, not just files. See more about what Mac can do here: Six background window tricks | Macworld (

This needs a system level change because of how events are processed. Both Wayland compositors and X11 window managers will activate the background window as soon as the mouse button is pressed in it. They cannot determine that the button press might start a drag, and the apps can’t refuse to be activated.

There was a lot of discussion about this, including KDE people, almost 20 years ago. Here are some of the threads:

There has also been occasional discussion on the wayland-devel mailing list, though I’m having trouble finding the threads right now.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.