Improve tiling edge window previews: add "hover to activate" options

[jtaala]

Fixes #779.

This PR implements the following improvements to tiling edge window previews:

• fixes an issue where edge previews set stuck (don't disappear);
• fixes timing issues with continuous window (activation);
• adds an option to disable edge previews (simpler option compared to setting size to 0);
• adds an option to activate edge window by hover (see Automatically scroll on hover #779);
• adds an option to set the timeout in (ms) for hover activation;
• adds an option to enable/disable continual activation of edge windows on hover (e.g. if pointer is still at edge).

[Thesola10]

Feels nice to use, but it doesn't seem to react while dragging a window, which is arguably an important use case

[Thesola10]

Also maybe require pushback or some other continued movement for consecutive scrolling so as to not cause unwanted movement just leaving the pointer at rest on screen edge

[jtaala]

Also maybe require pushback or some other continued movement for consecutive scrolling so as to not cause unwanted movement just leaving the pointer at rest on screen edge

Oh lol, I specifically added that behaviour because it felt nice to leave the mouse there and continue to activate with a timeout...

I can put an option to enable/disable that behaviour I guess.

[jtaala]

Feels nice to use, but it doesn't seem to react while dragging a window, which is arguably an important use case

This one will likely need to wait. DnD's need a target to detect / activate clutter actors (basically same issue as #574) - which means we'll need to use a PointerWatcher to detect the pointer being on the edge (when it's dragging a window) to activate an edge window.

Doable, but means we need to rewrite StackOverlay approach to use a single PointerWatcher to detect pointer being at any monitor edge (instead of two clutter actors to detect pointer entry/exists). That way, we can trigger preview (and timeout activations) - regardless of if we're dragging a window or not.

I think that's the issue anyway. I'll get this PR in and have a look at the a PointerWatcher based implementation for this.

[jtaala]

I think that's the issue anyway. I'll get this PR in and have a look at the a PointerWatcher based implementation for this.

@Thesola10, if you're interested, I created a quick implementation of pointerWatching edge positions. It's responding to dragged windows (if you turn on activate on hover)... still not switching though so the dragging must be blocking the Main.activateWindow() call (or something else going on there): 676defe

https://github.com/paperwm/PaperWM/tree/experimental-drag-drop-edge-window-previews

This breaks button press on preview (disabled) - so if just experimental / concept testing atm.

[jtaala]

I think that's the issue anyway. I'll get this PR in and have a look at the a PointerWatcher based implementation for this.

@Thesola10, if you're interested, I created a quick implementation of pointerWatching edge positions. It's responding to dragged windows (if you turn on activate on hover)... still not switching though so the dragging must be blocking the Main.activateWindow() call (or something else going on there): 676defe

https://github.com/paperwm/PaperWM/tree/experimental-drag-drop-edge-window-previews

This breaks button press on preview (disabled) - so if just experimental / concept testing atm.

Anyways, some rethinking on concepts and implementations there - will have to tackle / look at that one at some point. Won't be in this PR though.

[jtaala]

Also maybe require pushback or some other continued movement for consecutive scrolling so as to not cause unwanted movement just leaving the pointer at rest on screen edge

Added an option to enable/disable this behaviour (if disabled, it won't activate consecutive activation - e.g. will have to move pointer away and back again... or click if you have click to activate enabled).

[jtaala]

P.S. try that one out (with continual activation) - if still doesn't feel right (having to pull mouse back and retouch edge), then we can look at adding a PressureBarrier for continual activation.

[Thesola10]

Yeah I think I'd prefer a Pressure barrier, nonconsecutive just feels worse

Also experimental branch doesn't seem to track moving windows at all? idk

[jtaala]

Also experimental branch doesn't seem to track moving windows at all? idk

Well, it's "working" in the sense that it overcomes the main issue with dragging windows and previews (detection of when the dragged window is at the edge). Normally, you'll get no reaction or preview showing. In experimental branch, you'll get this:

Screencast.from.2024-05-06.21-39-31.webm

The flashing preview on the edge (when dragging) is just showing that it's detected and it's trying to activate the next window (but as I mentioned there's some other issues blocking that). Still, it's just showing that using a PointerWatcher we can then detect when it's at an edge (whether dragging or not).

I.e. we'll have to rewrite StackOverlay.js to use a global pointerWatcher detects when it's at an edge - instead of current StackOverlay Clutter actors.

[jtaala]

Okay, all, have experimented with pressures barriers and mouse "pushback" to non-consecutive hover activation. Pressure barriers don't work that well unless we move the mouse back a bit so the barrier resets.

In any case, I've now implemented mouse "pushback" for non-consecutive hover activations. That is, after activation, we "push" the mouse back several pixels. This means you can avoid accidental activations (by leaving the mouse on the edge), and if you want to show next preview, you can nudge the mouse against the edge again.

Consecutive (continual) is still an option in the settings.

[jtaala]

I do like the feel of this one (non-continual), even with a hover time of 0ms (instant activation).

[Thesola10]

Oh yeah, feels really nice with 0ms, lgtm

[Thesola10]

think we could make the pushback a bit earlier so pressure action feels actually consecutive and doesn't wait for the end of the previous animation?

[jtaala]

think we could make the pushback a bit earlier so pressure action feels actually consecutive and doesn't wait for the end of the previous animation?

Not sure I properly understand what you're suggesting (and how it would work), but feel free to play around with modifying this behaviour and seeing how it feels. You'd probably want to change this: (which actions an edge-check and shows preview after animation time):

PaperWM/stackoverlay.js

Lines 224 to 235 in 4deb4f7

	this.triggerPreviewTimeout = GLib.timeout_add(
	GLib.PRIORITY_DEFAULT,
	(Settings.prefs.animation_time * 1000) + 50,
	() => {
	if (this._pointerIsAtEdge()) {
	this.triggerPreview(true);
	}
	this.triggerPreviewTimeout = null;
	return false; // on return false destroys timeout
	});
	}