I still think Tkx was a good idea, but I've an open mind. On both ends? :) See Tcl::Tk -- gisle worked on this as well, its much better in all respects than Tkx. Tcl::pTk is even more better.
| [reply] |
Thank you. I shall look at this. The TkDocs website makes Tkx look like the best solution. But I had trouble trying to utilise the MainLoop to do what I wanted. The Tcl docs at www.tcl.tk were a bit opaque on the subject.
I think that the fusion of Tcl and Tk with Perl hold great promise for Perl programmers. I want to see many more Perl GUI programs. I don't understand why so many Perl programmers are anti-GUI. Why can't Perl be the best at everything, not just at command line scripts?
| [reply] |
I don't understand why so many Perl programmers are anti-GUI. Why can't Perl be the best at everything, not just at command line scripts? Its just your imagination :)
Its like saying so many knife users are anti-Shaving ... shaving requires high sharpness and high polish ... most of the time you're not shaving ;)
| [reply] |
I don't understand why so many Perl programmers are anti-GUI.
I don't think they are anti-GUI, they simply learned that command line tools tend to cooperate better than GUI tools. A GUI is the last step of development, not the first step, and it is completely optional.
One of the Unix design ideas is to have several (smaller) programs communicate and cooperate to solve a large problem. One program to sort, one program to extract data, one program to merge data, one program to create two data streams from one, and so on. A kind of "Lego with programs": You can build castles, cars, space ships, and much more from the same few basic bricks. All that works best from the command line. No GUI needed, except for opening several command line windows. On top of that, you can build some GUI program that wraps some command line tools, to make common tasks "mouseable". Or, you add a web server to invoke the same command line tools from a CGI or similar. Or, you invoke the command line tools from cron every night. Or you construct a service using daemontools or simply inetd.
Perl came into the Unix world as a "better glue", replacing what was done before with shell scripts glueing together (too) many (too) small helper programs. But it kept the spirit of cooperating with other programs by using the established conventions: read data from STDIN, @ARGV and %ENV, write data to STDOUT, write warnings and errors to STDERR, preferably all in a way that other programs can post-process the output.
Compare that with controlling GUI-only programs. You can not (or hardly) combine them, all you need has to be in the one program you use. You may use the clipboard, or at best OLE or AppleScript. To automate GUI programs, you also have to mess with functions to find windows, buttons, text fields, to fake keyboard and mouse input, and to read text from buttons, windows, and GUI elements. And you have to make sure that the user does not touch the mouse and keyboard while your script tries to automate one or more GUI programs, or things will go awfully wrong. And: you need a graphical screen, either local or remote, to be able to work with a GUI. Command line tools can work with any terminal, or in case of webservers, daemontools, inetd, cron, completely without a terminal.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
