But it's "good enough" like 99% of the time? And going from 0 to "something with a button a user can click" is crazy easy. At my old job, before I started working for myself, I built some painfully sprawling python script to:
1) Spin up a selenium browser to access something in servicenow that they wouldn't let us query the API for but required we access 2) Control the downloading of a bunch of files from a tk interface from python 3) toggle various settings and parse through a bunch of downloaded spreadsheets from there and another website that had some data on 4) python and matplotlib then drew pretty pictures for management 5) python then spit out documents and charts in various formats 6) then a button click triggered it all to process in parallel and opened an email to the appropriate managers that I fire off
This turned something like 10-40 hours of manual work (depending on how well you knew how to do it) where you were clicking and reading into like a 15 min job that I could do on the first of the month while I drank my coffee.
I'm sure it would probably be "better" to write the whole program in Tcl/tk, but sometimes I am lazy. Also, if I'm doing something with pandas or AI and the tk gui is just something slapped over the underlying logic and code. I guess it's a matter of preference? But tkinter is "pretty good" and often "pretty good" is way better than perfect.
They say in the article something like, "if you don't need to call python libraries just use tcl/tk" or whatever. And that's fair, but honestly, being able to throw pandas at something or matplotlib or whatever is super valuable. I think in the future maybe it'll be easy to do something like, "claude please port matplotlib into tcl" and then you can do it natively, that would make sense? Or maybe even like they say it might be cool to make a python script then call it from tcl like they say? but multiple scripts in different languages seems like a bit of a maintenance headache? Though that also might be just a skill issue on my part lol. It might be lazy of me but staying in one language has some advantages, namely, I don't need all the boilerplate argparse code for each thing in python I might want to write.
When I wrote the monstrosity above, I didn't really know anything about tcl/tk other than "isn't that that archaic ui thing?" I actually played around with raw tcl during the process of writing that beast, but that was mostly just for fun.
I guess my real response is, if I end up in a knife fight with a GUI layer over python again, the way they describe in there might be what I do? Calling the python from the tcl might be the optimal choice? It'd be fine to stretch the brain in a slightly different direction anyway.
that sounds a bit worrying. can you give some examples?
from the article i was specifically wondering about this:
And yet still, even with ttk, Python doesn't automatically pick the best theme for the OS! It often defaults to "clam", "alt", or the dreaded "classic" on Linux, which look dated. It's a mess of a Tk bridge! ... the provided bridge to it is clunky
so is it just the perception? sounds like i should just have to remember to pick a better theme. (and use ttk)
and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
Sure you can make this module and there are probably things out there, but you need to wire it up yourself before you even get to the application logic.
Last time I had to make a quick tkinter interface was like a month ago for a project I was working on just for me and I wanted a cleaner interface and I just had codex do it and it was "fine" - like nothing to write home about but "fine." If you're trying to get the most out of your macbook or whatever, the default is kind of bad.
I would say you're correct, it's perception.
> and what you say about using pandas supports my point. i usually want to add a gui to something that is written in a particular language for a reason.
This is exactly why I never even thought to use Tcl to call python before, because you'd end up with something like this for each function you wanted to call in python:
import argparse
from other_library import super_important_function
def do_the_thing():
parser = argparse.ArgumentParser()
parser.add_argument("--data_file", type=str, default="report.dat")
args = parser.parse_args()
super_important_function(args.data_file)
if __name__ == "__main__":
do_the_thing()
And I guess the question is, do you want to be doing that 20 times for your Tcl app, or do you want to just write a python app? In my mind, a "pure" python app in this case is probably smarter, because you could do something like this: import tkinter as tk
from tkinter import filedialog
from other_library import super_important_function
def open_file():
filename = filedialog.askopenfilename()
# now bear with me, I always have to remember if filedialog and the like
# return strings or pathlikes, but you get the picture...
if filename:
super_important_function(filename)
root = tk.Tk()
root.title("Pick a File")
button = tk.Button(root, text="Do super important thing on file!", command=open_file)
button.pack()
root.mainloop()
I guess it's personal preference at a certain point, yah. I would say "just use ttk and pick a good theme" is probably the right call. They mentioned some stuff about concurrency in the article and tcl being guaranteed to be responsive, etc. Despite abusing the hell out of tkinter in python, I had no problem rendering multiple windows I had up while I had pandas grind away tens of thousands of datapoints, so YMMV, but tkinter in that application worked fine. But from a "code maintenance" and "bus factor" sort of thing, I would say this is probably easier to figure out wtf is going on with a tkinter app over calling a bunch of python scripts from your Tcl app? But again, it's preference.One of the things I really don't like about big complex tkinter apps (and this may very well be a skill issue on my part) is that in my experience if you're not really careful they tend to end up being monolithic apps with functions and windows bolted on as needed, and the parent/child relationship between windows gets confusing. Again, this is likely just me being dumb at precisely the wrong time, but I kind of think think the python of it is a little bit kind of confusing. I've thought about trying to get good enough at Racket or something similar to build a DSL for generating tkinter python interfaces? But honestly, I haven't really had both the need for something like that or the time. That said, it would be awesome do have something where I could do:
<root layout="grid">
<label row=0, col=1>Hello world</label>
<button row=1, col=1, callback=cool_function>click me!</label>
</root>
And have that emit clean python? But... in the world of LLMs etc. I don't know that the juice is worth the squeeze?Still, wrt the article, I could totally see a situation where it would be better to wire a bunch of other scripts together with Tcl. Imagine your shop has utilities and tools in Go, Python, Bash, whatever. and you needed to wire them all together? That would be an excellent case for doing something like what they described. And like I said, I might try this on the next project where I need a quick GUI.