>you can have Tk (as long as your Cobol allows you to call C).
replyNo C required, you can just connect to the UI through a socket and often skip the FFI completely. This is my preferred way to use Tk and I don't even consider anything else unless there is a reason. Working this way also has the nice side effect of making the application UI agnostic.
But then you have an entire front end written in Tcl or some other non-COBOL language (to continue the above example,) right?
replyOr is there a way to run Tk as a daemon?
Believe you have to do that anyways unless you are going to create full language bindings as tkinter and the like do. I don't know the Tk API in full but I don't believe it provides ways to create widgets, just interact with them more directly. Perhaps someone more knowledgeable will fill in the gaps here, I learned what I needed of the Tk API and called it good.
replythat sounds interesting. can you give an example please?
replyPureData is a good example.
reply> interfaces to Tk
replyIt interfaces to its own internal Tcl interpreter that runs Tk. You can even feed it arbitrary non-Tk commands to eval.
This is a legacy of the trouble Perl/Tk had splitting it out as an independent library which the Tcl devs didn't want to support.
When I first found out about Tcl/Tk, it was used to give a GUI to programs written in C. I've used Tk with Tcl and many times with Perl too.
replyin what way is Tk basic? can you elaborate? also what are your thoughts on the issues with python as mentioned in the article? how do the scheme bindings compare?
replyThis is a fun idea! Are you using Guile-tk?
reply