I've read that TCL has its origin as a command language for EDA tools. I also remember an old QA acquaintance mentioning that some tools translated every GUI action taken by a user into a a TCL statement. These statements were then logged into a file. They mentioned being able to reproduce any bug by just re-running the log file of commands.
This seems like a powerful pattern.
Was there a general set of rules to pull this off. For example, what if the user is in a CAD app. If they create a line with one statement, how would they refer to the line later on in order to manipulate an attribute of the line?
Every action in a Tcl/Tk GUI results in the calling of a Tcl script; the controller in a Tcl/Tk application is the Tcl interpreter. Some of these scripts are supplied by Tk itself (e.g., defining what happens when you move the mouse over a button) and others are defined by the application code (e.g., what happens when you click on the button). By recording all these little scripts, you can replay exactly what happened to the fullest degree.
It's not normally necessary to record everything. Just tracking the actions, the record of what changes were made to the underlying model (and not just to the display state of buttons and stuff like that) and that's almost certainly what your acquaintance was talking about. In the case of such a logging approach, you're not really talking about doing significant later processing in the same program: you're producing a text file where each line corresponds to one action, and where each line is actually a well-formed Tcl command, as that's trivial to do (the
listcommand is ideal for systematically creating correctly-formatted Tcl commands).However, if you are recording a log so that you can go back to it and edit it within the application, or take another path, then you're going to need more than just a text file. One simple (and fairly crude) approach might be to keep that text log file in a SCM like git; that would allow for going back in time, branching, all sorts of interesting capabilities. Beyond that, you can think instead of keeping the record of actions (each of which would still be a Tcl command call) in a database (SQLite works very well with Tcl, but there's good integration with many other DB engines too) and that would give you the sort of capabilities you want: the properties of a line could still be done with simple text manipulation — it's just working with a Tcl list on structured data, so it's both simple and powerful — yet you've got the database to support you as well. That's where you can get very creative indeed, beyond what I can reasonably cover in a Stack Overflow answer.