Do I need to put all the "functional" parts of the script in subroutines in order to be able to trigger them with Tk GUI button presses and such?
Whilst you could do it that way, as you point out, it means making extensive modifications to (presumably) already working code. It also means letting your tool (Tk) dictate the architecture of your application which is never a good thing. Especially as it would make turning the gui off for those gui-phobic *nix users very difficult.
IMO the best alternative would be to stick your TK GUI into its own thread with a queue and tie that queue to stdin & stdout.
Now you make the decision whether the enable the GUI at start up and if you do, and of your existing output to stdout goes via the queue tied to stdout and gets displayed in a listbox on the GUI. And any requests for input (Eg.my $var = <STDIN>; get fulfilled from the queue, having been source from an edit field on the gui and placed into the queue.
The main body of your code doesn't change at all. You just add:
use My::Gui; ... if( $opts{gui} ) { tie *STDOUT, 'My::Gui'; tie *STDIN, 'My::Gui'; async( \&My::Gui::gui )->detach; }
at the top of your program.
In reply to Re: Perl/Tk code structure
by BrowserUk
in thread Perl/Tk code structure
by elef
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |