feat: Super + Shift + Right Click or Super + Middle Click to open window context menu

[Koranir]

This PR fixes #909

Using either

• Super + Shift + Right Click or
• Super + Middle Click

opens the window context menu at the cursors location.

I avoided the Super + Right Click tap as it conflicted with window resizing, and it can be hard to keep the cursor still while clicking.

Something I'm not too sure about:

• The grab unset at the former src/input/mod.rs:789: it doesn't seem to do anything that the ResizeGrab and MoveGrab weren't doing themselves, and kept deleting the MenuGrab - am I missing something?

[Koranir]

I was missing something

[Drakulix]

I avoided the Super + Right Click tap as it conflicted with window resizing, and it can be hard to keep the cursor still while clicking.

This could be solved by adding a little bit of tolerance before considering a move significant enough to trigger the resize behaviour. E.g. something like "more then 10 display units in any axis".

Which would still be the preferred solution to this problem.

[Koranir]

This could be solved by adding a little bit of tolerance before considering a move significant enough to trigger the resize behaviour. E.g. something like "more then 10 display units in any axis".

Is there a general setting/recommended value for tolerance or is it just ad-hoc? It's a fine line to tread in my experience for these arbitrary values.

I'm fine with changing the behaviour to something that could debatably be more intuitive, but I'd prefer to stay on the side of unambiguity.

[Drakulix]

Is there a general setting/recommended value for tolerance or is it just ad-hoc? It's a fine line to tread in my experience for these arbitrary values.

I don't think we have this problem in another part of cosmic-comp yet, so no. The exact value here would need to be "felt out". Just add a constant with an arbitrary value you feel that work well and we will tweak it from there.

I'm fine with changing the behaviour to something that could debatably be more intuitive, but I'd prefer to stay on the side of unambiguity.

I personally have nothing against providing an unambiguous trigger additionally, but any changes to the agreed upon solution in #909 would need to go through @pop-os/ux.