feat: Add Undo as an Action variant + double-click to trigger actions-on-enter

[clansty]

Feature Request

1. Undo as an Action variant

Currently the Action enum supports save-to-clipboard, save-to-file, save-to-file-as, copy-filepath-to-clipboard, and exit. These can be composed in actions-on-enter, actions-on-escape, and actions-on-right-click.

I'd like to propose adding undo as a new Action variant. This would allow configurations like:

--actions-on-right-click undo,exit

Semantics: undo is a fallible action — if it succeeds (something was undone), stop processing further actions in the list. If it fails (nothing to undo), continue to the next action. This makes undo,exit mean "undo one step; if nothing left to undo, exit".

Use case: Right-click-to-undo is a common interaction pattern in annotation/drawing tools. Combined with exit as a fallback, it gives a natural "undo or cancel" flow without needing a dedicated config flag.

2. Double-click to trigger configurable actions

Add --actions-on-double-click as a new configurable action list, consistent with the existing actions-on-enter, actions-on-escape, and actions-on-right-click options.

When actions-on-double-click is not set (empty), it falls back to actions-on-enter behavior for backwards compatibility.

Double-click is only processed when the active tool does not stop propagation, so it does not interfere with existing double-click behavior (e.g. text tool word selection).

Use case: Double-click to confirm/copy is a natural gesture for screenshot crop workflows.

[RobertMueller2]

Semantics: undo is a fallible action — if it succeeds (something was undone), stop processing further actions in the list. If it fails (nothing to undo), continue to the next action. This makes undo,exit mean "undo one step; if nothing left to undo, exit".

I don't find this very intuitive. If action chains had any control flow, which may be something to consider in #89, I could see fallible actions. But it would have to be something explicit along the chain, not implicit in the action.

FWIW, undo likely is by an order of magnitude more fallible than save or copy.

Use case: Right-click-to-undo is a common interaction pattern in annotation/drawing tools.

Do you have any examples for this, please?

Combined with exit as a fallback, it gives a natural "undo or cancel" flow without needing a dedicated config flag.

Er... I do not find this natural at all, sorry.

Add --actions-on-double-click as a new configurable action list, consistent with the existing actions-on-enter, actions-on-escape, and actions-on-right-click options.

Maybe. I think we could merge that. But in the long run, I'd kinda prefer if on the back of #89 we have less explicit flags and instead more generic trigger-action bindings.

When actions-on-double-click is not set (empty), it falls back to actions-on-enter behavior for backwards compatibility.

No, let's not do that, please.

Use case: Double-click to confirm/copy is a natural gesture for screenshot crop workflows.

Is it though?

[clansty]

Thanks for the review!

On undo and fallible action semantics:

Fair point about implicit control flow — I agree it's not great to have the chain behavior depend on an action's success implicitly. Two possible directions I can think of:

1. Make undo a plain action that always continues the chain (no-op if nothing to undo), and add a separate compound action like undo-or-exit for the "undo one step; if nothing left, quit" use case. No implicit control flow — the compound behavior is explicit in the action name.
2. Keep undo as a plain action only, and leave the compound use case to [feature] link upload and/or additional buttons with custom functions #89's more expressive system.

Happy to go with whichever you prefer — or something else entirely.

On right-click-to-undo examples:

Snipaste and PixPin both use right-click-to-undo in their annotation modes.

On --actions-on-double-click:

I'll drop the fallback to actions-on-enter — when not configured, it simply does nothing.

Re: #89 and generic trigger-action bindings — totally agree that's the better long-term direction. Since it's not implemented yet, I'd like to land --actions-on-double-click as a standalone option for now and migrate to the generic system when it arrives.

Both Snipaste and PixPin use double-click to confirm/save in their screenshot annotation workflows, which is where this idea comes from.

[RobertMueller2]

On undo and fallible action semantics:

Fair point about implicit control flow — I agree it's not great to have the chain behavior depend on an action's success implicitly. Two possible directions I can think of:

1. Make undo a plain action that always continues the chain (no-op if nothing to undo), and add a separate compound action like undo-or-exit for the "undo one step; if nothing left, quit" use case. No implicit control flow — the compound behavior is explicit in the action name.

2. Keep undo as a plain action only, and leave the compound use case to [[feature] link upload and/or additional buttons with custom functions #89](https://github.com/Satty-org/Satty/issues/89)'s more expressive system.

Happy to go with whichever you prefer — or something else entirely.

I'd prefer option 2 because I think that keeps it cleaner for the future when #89 is implemented.

On right-click-to-undo examples:

Snipaste and PixPin both use right-click-to-undo in their annotation modes.

Thank you for the examples.

On --actions-on-double-click:

I'll drop the fallback to actions-on-enter — when not configured, it simply does nothing.

Re: #89 and generic trigger-action bindings — totally agree that's the better long-term direction. Since it's not implemented yet, I'd like to land --actions-on-double-click as a standalone option for now and migrate to the generic system when it arrives.

Both Snipaste and PixPin use double-click to confirm/save in their screenshot annotation workflows, which is where this idea comes from.

Ok, thank you for the context. I think we might want to flag this as experimental. Implementation of #89 (specifically the part requested in #450) might make binding things easier or more generic, and then it would be good not to have to keep a huge number of legacy config options and cli parameters.

One last thing, if it's not too much effort (haven't looked at the code in #482 yet), I think these are two distinct issues and PRs, one issue and PR for double-click and one issue and PR for an undo action.