jdoda / hotedge

A GNOME Shell extension that replaces the top-left hot corner with a bottom hot edge.
GNU General Public License v2.0
57 stars 5 forks source link

Don't activate overview if mouse button is held down. #9

Closed jdoda closed 2 years ago

jdoda commented 3 years ago

If the mouse button is held down and the edge would otherwise be triggered, don't trigger. The hot corner already works this way, so I must have broken it somehow (I have some ideas).

sfllaw commented 3 years ago

I'm using xorg and it is broken for me too, so it's not just Wayland

sfllaw commented 3 years ago

If you fix this, can we revert corner-deadzone from c448e314603457cb103d034f61f9d5179c253b74?

jdoda commented 3 years ago

I did some more investigation and the current behaviour is a little different than I thought. Under Wayland both the hot corner and hot edge can be activated while dragging (tested while dragging a file from Nautilus and a scroll bar), but under Xorg (at least on my machine) the hot corner can be activated while dragging a file from Nautilus, but the hot edge can't, and neither can be activated while dragging a scroll bar.

I suspect that what I thought was intentional behaviour (the hot corner not activating during drags) was actually just an unintentional result of the way input grabbing works in X. Not really sure what I want to do about this now.

sfllaw commented 3 years ago

It looks like imports.ui.layout.HotCorner has an explicit method to handle drag and drop: https://github.com/GNOME/gnome-shell/blob/374a2b2c511d2781492a96520f24a93e6da196f6/js/ui/layout.js#L1197-L1204

    handleDragOver(source, _actor, _x, _y, _time) {
        if (source != Main.xdndHandler)
            return DND.DragMotionResult.CONTINUE;

        this._toggleOverview();

        return DND.DragMotionResult.CONTINUE;
    }

I wonder if implementing something similar might Do The Right Thing?

jdoda commented 2 years ago

Ideally the behaviour we'd want is for the overview to open during the drag phase of a drag-and-drop action, but not if the mouse button was held down for some other reason (e.g. moving a scroll bar). I made an attempt to implement this behaviour, but it doesn't seem to be possible to do in an extension. If anyone has any idea of how to do this without patching Gnome Shell I'm open to suggestions, but for now I'm closing this issue.

sfllaw commented 2 years ago

@jdoda Does the handleDragOver delegate not work? It's documented here: https://github.com/GNOME/gnome-shell/blob/78c7d5ba0c608ca4586416c861619cd8b6bb61c8/HACKING.md#actor-deprecated-and-_delegate

jdoda commented 2 years ago

No, unfortunately it doesn't work. It was one of the first things I tried.

Under X11 the problem is that for the handleDropOver method to be called the hot edge actor needs to actually have an on screen position, and needs to be reactive (this is true in fallback mode, but when using pressure barriers the hot edge isn't actually added to the shell layout). The problem with doing that is that you can no longer select icons on the dash when your cursor is at the very bottom of the screen (like it would be just after you activate the hot edge) because the hot edge is covering that space.

You can actually sort of make it work by making the hot edge actor non-reactive, and hooking into the signals that XdndHandler provides directly, to track whether or not a drag is in progress. Unfortunately, these signals aren't emitted under Wayland.

I've explored (afaict) the full range of functionality provided by XdndHandler, Meta.Dnd, dragMonitors, etc, and I can't find anything that works under Wayland.

jdoda commented 2 years ago

Though, in the mean time I've actually made suppressing activation when a mouse button is held down the default in the latest update. There's a preference UI now where you can switch it off if you really miss being able to drag-and-drop, but I've seen enough reports now of accidental activation that would be solved by suppression that I now think it's more important than drag-and-drop.

sfllaw commented 2 years ago

This is very, very unfortunate. Thanks for the explanation.