History Feature

I thought to suggest a command UNDO feature. Because I know that programming an UNDO for every command could be difficult or time-consuming I thought maybe just an UNDO for tuning would be good enough and would be easier to implement. Then I saw existing discussion of a command UNDO and I didn't want to revisit an idea that's apparently been discarded. So here's a new idea that proposes a different way to get to the same place.

How about a tuning history like the URL history feature in a web browser? Any time you wanted you could pull up the history (which might hold a limited number of tuning actions) and see what tuning changes had been made, from most recent to oldest. And by clicking on a frequency you could trigger an action that asks what panafall/slice you want to tune. The action also gives the option to add a new slice within an existing panafall or a newpanafall, if resource levels permit.

How would this look? You'd list each existing panafall and, at the bottom, you'd provide a means of creating a new panafall. Within each existing panafall you see the slices, ordered by frequency. At the bottom of the list, you'd provide a means of creating a new slice within that panafall. Of course, if the system has no available panafalls or slices, the related action would be visible but disabled. It would be very easy to use this structure. Most often you'd quickly find the slice you want to tune and then click it.

It would be possible to present the information differently. You might disregard the panafalls and provide an alphabetical list (or a list sequenced numerically, by frequency) of slices. That's more streamlined. But then the action of adding a new slice becomes more difficult because the user must somehow identify the panafall in which the slice is to be placed.

When I write this out it sounds rather complex. But just think about the way the Chrome browser's history works and suppose you had something similar that would remember and let you re-do tuning actions. 

Yes, this can already be done by some external rig control programs. That merely shows that the function is useful and not impossible to develop. It would be best to have this feature inside SSDR rather than an external program.