Marquee selection on canvas (replacing redundant click-drag pan)

[EduCoder26]

Right now, click-and-drag on empty canvas pans the viewport. That's redundant since 2 finger and 3 finger swipe already do the same action, and I've found a better action for click-and-drag: marque selection.

Basically, you click and drag on the background to select one or more windows, and then you can move the windows in bulk or close them with a keybinding.

There's minimal implementation cost, since I've already implemented it in my personal DriftWM setup, I just needed to open an issue to see if I can open a PR given the contribution instructions.

Question: should the close selected action be instant, or require extra confirmation?

[SputerSnoot]

Have you tried move-snapped-windows that moves the whole group of windows snapped together? At first i wanted to have a select rectangle feature but this action solved the problem for me

[malbiruk]

Thank you for the suggestion.

@SputerSnoot exactly -- the solution for the problem already exists -- all the "snapped" actions. With adding this selection we'd have 2 parallel grouping paradigms, which can result in strange situations like if you select already clustered windows -- what would happen on cluster/marquee selection move?

And adding marquee select isn't as small as it seems -- it's its own mode essentially. When you select windows you need to update their chrome, and they need to wait for your next action, you rarely can move window in single flick, so you'll need also an exit semantic (esc? click on empty canvas? same binding repeated?). And regular actions like move/close window -- they'll need to be overriden during active selection? Moreover windows can resize, auto-close or go fullscreen etc., become pinned during selection. So, actually, the surface is much bigger than it seems.

Also click-and-drag is redundant only for trackpad users, for mouse users it's basically the primarily way to navigate canvas.

So I lean into declining this suggestion unless there's some kind of workflow not solvable by current snapped semantic. Also driftwm deliberately is almost invisible, so it feels just as an empty canvas only with your windows. Popup confirmation would go against that.

[malbiruk]

No counter-examples surfaced since the discussion above, so closing as not planned: the snapped/cluster actions already cover group-move, and a marquee mode would introduce a parallel grouping paradigm plus a lot of hidden mode surface for little gain. If you (or anyone) hits a concrete workflow the snapped semantics can't express, comment here and I'll reopen.