|P is for Practical|
Re: TclTk interface with Perl code, is it possible?by Marshall (Abbot)
|on Jan 13, 2012 at 16:02 UTC||Need Help??|
Wow! Your post covers a lot of ground!
As far as making a .exe for Windows, I would give a "thumbs up" to the Active State PerlApp program. Over the last decade plus, these folks have improved this thing so that it works pretty well now and I am user. The most basic Active State devkit will set you back a couple of hundred bucks, but in a professional environment this will save a lot of hassle and aggravation!
You don't say what you are using now for building .exe's. One of the issues with a Tk based .exe is getting all of the necessary stuff into the .exe. When you run from your environment just "use Tk;" may be all you need because many widgets that are used are found dynamically during run-time. When I write Tk code destined for a .exe, I reflexively just put in a "use Tk::Label;" or whatever whenever I use a new widget in the code. That is one way to "force" the Label widget into the .exe.
However, Active State has developed a number of heuristics that scan the source code and automatically include the necessary widgets! This is very helpful! The alternative is to run the .exe, exercise all possible widgets to make sure that they are there and do something to get the "missing ones" when a run-time bomb happens - adding a "use" statement in the source code is, I believe better than adding command line compile options. However, it is even more robust to have Active State figure this out at "exe build time". In the old days, I'd miss one and have to repeat the build, test, modify cycle many times.
Anyway having the "smart" PerlApp that knows about Tk methods saves a lot of hassle and prevents errors of omission that are only apparent at run-time.
One advantage of using an older toolkit, like Tk is that there are a lot of books and examples available. I liked "Mastering Perl/Tk" by Steve Lidie and Nancy Walsh. This will show you how to write a lot "smarter", easier to understand and ultimately less code for the same job. Build "widget factories" for similar things.
My experience with writing GUI's is that the amount of time that I spend planning the GUI is far, far more than the actual coding of the basic layout. I spend a lot of time with "pencil and paper". The #1 tip: draw a picture of what you want on a scratch pad and use more frames to get the geometry to work out! The most used geometry (simple pack, instead of grid or others) has served me well although GUI development is not my primary coding focus.
The aggravating parts that consume most of the time are dealing with various screen resolutions and things like mouse focus and binding issues. I'm not sure how much a GUI builder would help with that?, if at all.