[Feature request] Clipboard: Pasting with middle mouse button only works within borders of active client window about labwc

[ahesford]

Keyboard input is "undirected", but mouse input is "directed" by the cursor position. When you left-click on something, you expect action to happen where the cursor points (if something is actionable), not in some window potentially far removed from the cursor position. The same is true if you right-click and a context menu opens. Whether or not some window is active, I expect a menu for whatever window (or lack thereof) is under the pointer to respond. It would be confusing indeed if you right-click the desktop and get some other application's action menu rather than the label menu.

The same is true for middle clicks. When the cursor is over the active window, if there are multiple fields that accept text, I would expect the paste to happen in the field under the pointer, whether or not that coincides with where keyboard input might go. If you mouse over to some other window or the desktop, the middle click should respond as the client under the pointer wishes, not how the focused window wishes.

I'm opposed to changing this behavior even if it is possible to do so. I think it will be unintuitive and could lead to unintended paste actions that leak information. The fact that it works in X11 seems to be a bug that follows from its global input model.

[Consolatis]

This somewhat sounds like we do not activate (Focus) the window on middle click, but I think we do that by default:

<context name="Client">
	<mousebind button="Middle" action="Press">
		<action name="Focus" />
		<action name="Raise" />
	</mousebind>
</context>

Maybe our hardcoded defaults are out of sync with rc.xml.all here?

[GabiBaumann]

@Consolatis:
I'm not quite going with the defaults, I've modeled labwc behaviour after my ancient fluxbox config.
The relevant bits here are:
Middle mouse has a defined action only on the "Maximize" context and runs
<action name="ToggleMaximize" direction="vertical"/>.
The focus model is:
<focus followMouse="yes" followMouseRequiresMovement="no" />
(and focus also switches on Alt-Tab).

@ahesford:
OK...
I agree that mouse input is directed by the cursor position -- if there is any action defined for middle mouse.
But having a paste go to the active cursor, whereever that may be is definitely a feature in my book.
It saves half the "precision mousing" required for Copy&Paste. Just select something, Alt-Tab + middle mouse, the text goes to the cursor. Beautyful. Efficient. Reduces RSI. (My computer use is centered around a whole bunch of terminals on several desktops, the browser is about the only "GUI" thing around. That does not look to be the usecase you envision.)

Also I don't quite follow it's confusing. Rather it's what I expect from the desktop, and *box WMs et al. (can) do it like this at least since a quarter century... ...sometimes I feel old :) I think (and can try and verify this weekend) that KDE/Gnome running as wayland compositors can be configured to work like this...

But of course, weather you find this a reasonable thing to implement is up to you :)
Thanks.