Undo/Redo for changes made in the app/via physical buttons

[szszoke]

Pretty much the title.

[geoffreybennett]

Ooh, interesting idea.

Thoughts for a basic implementation:

The alsa_card struct would have an "undo list" that is appended to as changes are made, and an index into that list (for supporting redo). Each undo list element would contain the element control numid and the old value. On the first undo, the current value would be added to the end of the list before moving the index back one. The alsa_elem struct's value field will need to be maintained (not just for simulated elements like it is now) so that if a control is externally changed an entry can be added to the undo log.

Each undo list element would also need a "group number" so that if many things are changed at once (due to either alsactl restore being run or a preset being selected) they all get undone/redone together. Or instead of a group number, each undo list element is itself a list of control changes. Add a last-change-time field to struct alsa_card and if time() is within a fraction of a second of it when a change is made, then it is grouped with the previous change.

As usual for undo/redo implementations, doing undo then making a change would trim the undo list so you can't redo.

Question: How do you provide feedback if you are undoing/redoing and the window with the control is not open?

Hover over the undo/redo buttons could show what change it would make. Long-press on the buttons could pop up a menu with a list of changes going back/forward in time.

There's probably more that will become apparent during implementation. If you want to try tackling it, feel free to go ahead; it would likely be a long while before I could do this.