Clearlooks...
...how desktop applications still ought to look.
Tcl/Tk 9.0 has moved to Unicode and 64-bit data structures, and can now access compressed files as if they were file systems. It has been worth the considerable wait. The Tcl/Tk team doesn't rush into new versions. The previous major release, version 8.0, was in 1997, and the last minor release, version 8.6, came out in 2012. …
The "standard" GUI for Python is Tcl/Tk. It's part of the standard Python library, although many Linux distros make it an optional package.
Here's a quote from the Python documentation about it.
Tk/Tcl has long been an integral part of Python. It provides a robust and platform independent windowing toolkit, that is available to Python programmers using the tkinter package, and its extension, the tkinter.tix and the tkinter.ttk modules.
The tkinter package is a thin object-oriented layer on top of Tcl/Tk. To use tkinter, you don’t need to write Tcl code, but you will need to consult the Tk documentation, and occasionally the Tcl documentation. tkinter is a set of wrappers that implement the Tk widgets as Python classes.
I've used it when I needed a cross-platform GUI. It worked just fine for the job in question.
[Author here]
> The "standard" GUI for Python is Tcl/Tk.
I am not a Python person at all, but I think, according to my limited understanding, that `tkinter` is a wrapper around Tk, but that not much Tcl is involved.
As Wikipedia puts it:
«
Tkinter is a Python binding to the Tk GUI toolkit.
»
It's the Tk half, not the whole thing. Tk without its native programming language. Its package page on python.org says:
«
Tkinter is not a thin wrapper, but adds a fair amount of its own logic to make the experience more pythonic.
»
Here's the overview of how Tkinter works, from the Python documentation:
https://docs.python.org/3.12/library/tkinter.html
When your Python application uses a class in Tkinter, e.g., to create a widget, the tkinter module first assembles a Tcl/Tk command string. It passes that Tcl command string to an internal _tkinter binary module, which then calls the Tcl interpreter to evaluate it. The Tcl interpreter will then call into the Tk and/or Ttk packages, which will in turn make calls to Xlib, Cocoa, or GDI.
It appears to me that there must be a Tcl interpreter embedded in the Tkinter package. You as a Python programmer don't see any Tcl, but it's still there underneath.
Tcl was responsible for the worst abuse of a programming language I ever came across. A script with a few parameters would almost certainly sufficed but, no, Tcl was used to invoke vi and feed it with all the "keyboard" input to write a number of one-off scripts that were then run to do the actual backups or whatever. Just the sort of thing that happens when somebody says "This is cool - what can we get it to do?".
It worked. It was a good thing it worked because if it hadn't there's have been no indication of what a one-time script might have been doing. I should have replaced it with something simpler but, on the basis that I was just passing through as a temporary admin (not that temporary as it turned out) it didn't seem a thing to reverse-engineer and take on.
Yes, but you should not execute an interactive editor to create the scripts. Tcl can write them directly. It can also easily do itself whatever any shell script needs to do, because it can execute external programs easily (exec "program" "args" ...). The second solution is usually better, as it has less moving parts. Creating a script from Tcl makes sense only if there is some other component that needs a script as input.
The way Tcl syntax works has always reminded me of shell with commands followed by space separated options and arguments. The main difference is of course Tcl does not start a new process for each command, and the code for each command is already in the interpreter instead of loaded from disk, which makes it much faster.
I don't really write Tck now, but there is one tool written it it that I always use and carry around: the graphical diffing tool tkdiff. It is amazing the whole thing is only about 16 000 lines of code, and can process quite large files in reasonable time, despite being written in an interpretive language. Of course much of the grunt work is done by the "diff" tool of the host computer, but making a nice display of the results is still nontrivial.
I was able to call 'C' more or less directly from Tcl (man swig) and for wrapping test code I could get performance 1000x better than Perl could and write and deploy test case code about 100x faster than I could do the same in C.
The developers hated me, because the sheer rate that I could blast requests at the servers I'd been asked to stress test meant I uncovered all sorts of weaknesses that would otherwise only have shown up when the code being tested was deployed by large customers.
The payoff - :). I was never asked to play Red Team again ....