[Feature request] Key modifier to deactivate snapping

[jrgn9]

There might already be a way to do this, and I just haven't figured out how.

I want my windows to snap to tiles, so I disabled key modifier and secondary mouse button, so that a window always snaps. However, I have a couple of windows that I want to keep as floating. I would like to have a key modifier to deactivate snapping. So essentially flipping the way it works now by default.

I figured out it was best to keep using a modifier to activate snapping, so that I can keep those few windows floating. If there already is a way to deactivate snapping or if an deactivate modifier gets implemented, I would be really thankful!

[BasGeertsema]

Currently there is no way to reverse the process and disable snapping when using the modifier key. It is an interesting, although perhaps not very common, use case though. I will see if I can enable this feature in a way that does not feel too hacky.

[jrgn9]

I appreciate it!

It is not a matter of life or death, so I can live fine with another workflow if it turns out to be a big hassle to accomplish. If it is not super hard to implement, it would be great though

[JoergBr]

This would be awesome.

I use snapping all the time, so I don't want to press a button to do it every time (which is already possible of course). However, when I use small windows (like the calculator, for example), I would like to disable it with a key so that the small window stays as it is.

This is also possible in Fancy Zones from PowerToys and I would greatly appreciate it for Linux Mint.

Apart from this, the extension is perfect (especially the merge feature) - thank you very much for your efforts!

[webbertakken]

I've tried a fair few ways to make this work with the Esc key, but didn't get it to work with (yet).

I'll leave a summary here for the next person or agent who might want to continue this effort.

Escape-to-cancel: what we tried and why it didn't work

What we tried

1. Clutter event filter

Register a Clutter.event_add_filter from the extension that watches for KEY_Escape during the drag and short-circuits our session before Muffin's built-in handler runs.

Why it failed. Muffin installs its own Clutter event filter at display-init time via clutter_event_add_filter(NULL, event_callback, ...). Clutter iterates filters in registration order, so any JS filter we install runs after Muffin's. Muffin's handler sets bypass_clutter = TRUE on Escape during a MOVING grab, so the event never reaches us.

2. Cinnamon keybinding

Register Main.keybindingManager.addHotKey('Escape', ...) so our handler fires through Muffin's own keybinding path.

Why it failed. The hotkey is registered in Muffin's binding table and does get consulted, but process_event in src/core/keybindings.c has the line:

if (mouse_grab_move && !is_workspace_action(action)) goto not_found;

During a mouse move/resize grab, Muffin silently skips every non-workspace-action binding. Our handler is registered but never invoked.

3. Position-invariant heuristic

During a normal MOVING grab, Muffin keeps cursor − window_frame_topleft constant. Its built-in Escape handler breaks that invariant by calling meta_window_move_resize_frame(…, grab_initial_window_pos) — teleporting the window back without moving the cursor. We recorded that grip offset at every begin_grab_op and checked for a jump at grab-op-end.

Why it failed. Worked for Escape, but false-positived on ordinary fast drags. The offset we record in the main loop is always a few pixels behind the one Muffin uses internally, so active motion at the moment of grab-op-end looks to the heuristic like a teleport. Widening the tolerance (we tried 20 px) reduced false positives but the whole thing felt too fragile to ship.

The fundamental constraint

process_mouse_move_resize_grab in Muffin runs Escape handling unconditionally, synchronously, and before any JS-registered code can intervene. It moves the window back to its grab-initial position and ends the grab. From a Cinnamon extension, we cannot stop that — we can only observe it after the fact.

Realistic future routes

Roughly in order of effort:

• (a) Change the UX. Use a different key for cancel — one that Muffin doesn't special-case in the grab-op path — exposed as a setting. Simple and robust, but departs from platform convention.
• (b) Stabilise the position-invariant heuristic. Do the delta check against the last position-changed signal rather than a fresh get_pointer(), eliminating the main-loop timing skew. Accepts a small flicker because we'd only hide the overlay after Muffin's teleport.
• (c) Patch Muffin. Submit a two-line change upstream adding a grab-op-cancel signal, or allowing an extension to opt a window grab out of Escape-move-back. The correct place for the fix, but requires the patch to land in Muffin and then propagate through Mint — a long road.
• (d) Native helper. Dead end on X11: an out-of-process daemon using XInput2 passive grabs for Escape wouldn't see events while Muffin holds the active pointer grab. Would require replacing Muffin itself.

[jrgn9]

Thanks for taking the time to look into it!

This might be a stupid question, but why not use a different key for cancel? When I made this feature request, I was thinking something along the lines of having a "Key modifier to deactivate snapping" dropdown menu and just having the same key choices.

Or a better ux design would probably be something along the line of "Always active snapping mode" toggle, default it to false. Then the dropdown could be called something along the lines of "Key modifier to activate/deactivate snapping" and keep the same choices. And possibly change the toggle to "Activate/deactivate snapping with secondary mouse button".

This way, the workflow will be identical as having a key modifier to activate snapping, only the polar opposite.

[webbertakken]

Esc is kind of the intuitive thing you'd use. Personally I'd rather wait for a long term solution where Esc becomes possible. As that is what the key is for exactly.

[JoergBr]

Thank you for your efforts!

I also think that it doesn't need to be the Escape Key. In other Snap solutions (I think also with the MS PowerToys) you can define one key like Shift / Ctrl and decide between:
a) Snapping only when holding this key
b) Snapping always except when holding this key

This would make total sense to me for Fancy Tiles as well.

I actually don't know a snapping tool using Escape as the standard key / not letting the user choose the key.

If the deactivation functionality could be implemented with the same choice of keys as for activation, this would be great and absolutely fine from my perspective.

[webbertakken]

I'm not opposed to that either.

---

Just to explain my reasoning, as I was thinking more from a purity perspective from the semantics of the Esc key.

The Escape key on a computer keyboard serves as a universal command to stop, cancel, or exit the current operation, mode, or application. Its core semantic meaning is to interrupt a process and return to a previous, safe state.

Technically when you're in snapping mode, Esc would be the right key from a intuitive user experience and semantics perspective.

Example: "Go Back": Reverts focus from a submenu or dropdown menu to the main application interface.

This could be described as such a mode, and currently works across all operating systems, as they all follow this semantic.

From a UX perspective: if you don't know what the snapping windows do and you see it for the first time, your first instinct would probably be to press Esc - not to release your mouse button.

Source used: https://en.wikipedia.org/wiki/Esc_key

---

I actually don't know a snapping tool using Escape as the standard key / not letting the user choose the key.

You're right.

I've just verified the behaviour is in PowerToys FancyZones:

• Esc goes out of the mode, but snaps to the currently selected zone
• Holding Shift hides/disables the zones
• Pressing RMB a second time hides/disables the zones

---

The RMB a second time felt most intuitive to me and is what I used all the time. If you decide on merging #52, that one would actually be a very simple follow-up! Personally I'd be really happy with that approach.

Holding or or pressing shift shouldn't be difficult either.

[webbertakken]

@BasGeertsema what would you think about merging #52 (which honestly feels much more smooth than current behaviour, try it, I think you'll find the same) and following up with second RMB click to disable the zones?

I'd be happy to give the follow-up a shot too while I'm in context.

[BasGeertsema]

Hi @webbertakken Thank you for your efforts! This just a quick heads up. Tomorrow I have time to look into, and I will get back to you.