Add the ability to be able to hook up a custom action to Undo and Redo commands

[johnzhou721]

What is the problem or limitation you are having?

On platforms like macOS and Qt there is an Undo / Redo action. Recently, I've been making a game in which there will be a concept of Undoing that I want to hook up Cmd+Z to, but I cannot because the Undo / Redo actions are registered already.

Describe the solution you'd like

A way to call other custom handlers on Cmd+Z and Cmd+Shift+Z (and the like on other platforms). If appropriate, the menubar actions should do the same. Expose Undo / Redo actions for individual textfields os the override can call the default implementation of stuff depending on the focussed widget.

I'm wondering if Cmd+Z etc. may be managed by the system on some platforms, though, making this impossible.

Describe alternatives you've considered

Not have the override option.

Additional context

No response

[kattni]

Hey @johnzhou721. This will be addressed when the team returns the second week in January. Thanks!

[corranwebster]

@johnzhou721 if I recall correctly, some backends, like Qt and macOS have a full Undo/Redo system available (usually a stack-like data structure that you move back and forth through) and that's what the menu items hook into; and this stack can potentially be on a per-widget basis (eg. each Qt QLineEdit has its own stack). It looks like other backends, such as Gtk and Winforms don't have this system.

That said, at least with Qt (and possibly on a Mac) I think if you create a Command of your own with the name "Undo" or "Redo" it should replace any existing undo/redo menu items and keyboard shortcuts should work as long as the focus widget doesn't handle them for its own purposes.

A proper Toga implementation would involve the Document class growing optional undo and redo functionality, where changes to the data structure a mediated through a stack of objects which know how to apply and remove a single atomic change (there's a nomenclature problem, as these are commonly called "commands"–as in the Design Patterns book–but it is different from a Toga Command).

[HalfWhitt]

(there's a nomenclature problem, as these are commonly called "commands"–as in the Design Patterns book–but it is different from a Toga Command).

I'd nominate "action".

[freakboy3742]

Agreed that having a way to tie into undo/redo would be useful. The complication is how to make that undo/redo play nice with other types of undo/redo that are already supported (e.g., undo/redo of typed text in a text input).

A proper Toga implementation would involve the Document class growing optional undo and redo functionality,

I don't agree that Undo/Redo is necessarily tied to Document. Close integration with Document changes would obviously make sense, and any undo/redo implementation should be aware of that context; but it should be entirely possible to have undo/redo on an application that isn't document-based.

where changes to the data structure a mediated through a stack of objects which know how to apply and remove a single atomic change (there's a nomenclature problem, as these are commonly called "commands"–as in the Design Patterns book–but it is different from a Toga Command).

Agreed that this sort of pattern would likely be required - but I think there is (or should be) a fairly close relationship between Toga's Command objects and the sort of "classic gang-of-four Command" that you describe. A Toga Command is a unit of logic that can be triggered. That abstraction doesn't currently include undo logic - but it could. And a series of Toga Commands is really describing the set of things you're doing to an app. There may be a need for an additional layer of objects to describe things that have been done to the app that don't manifest as full Toga Commands - but Toga Commands are (or should be) undo/redoable entities.

However, step one in this space will need to be an investigation of what raw undo/redo APIs currently exist and how each native platforms expects developers to interact with those APIs.

[johnzhou721]

That said, at least with Qt (and possibly on a Mac) I think if you create a Command of your own with the name "Undo" or "Redo" it should replace any existing undo/redo menu items and keyboard shortcuts should work as long as the focus widget doesn't handle them for its own purposes.

A data point -- on Qt if you override Undo and Redo actions, that is the way those actions are handled, no matter the currently focussed widget. To get Undo and Redo to show up in the menubar, there is code that automatically calls the relevant functions on the focussed widgets.

A proper Toga implementation would involve the Document class growing optional undo and redo functionality,

I don't agree that Undo/Redo is necessarily tied to Document. Close integration with Document changes would obviously make sense, and any undo/redo implementation should be aware of that context; but it should be entirely possible to have undo/redo on an application that isn't document-based.

+1 on this. KDE, for example, has a calculator builtin that has undo and redo, sans a "document". Being aware of this context is also potentially helpful, as it may enable Qt Undo/Redo commands to be enabled/disabled correctly.