I've done this a few times and have my preferred practice, which comes with no "best practice" recommendation, but its something for you to consider.
The basic thing is that I construct the main script as a standard, command line, switch driven script. I then construct another script using the appropriate gui framework -- I've used Tk and Win32::GUI -- and use it to present the options to the user for selection and have a button that simply runs the script in the background with the arguments the user has selected.
Then I generally use a piped-open to run the command; as that gives me the pid for use with kill should the user decide to abort, and gives me access to the output from the CLI script, which I can the present back to the user either when the script has ended, or dynamically as the run progresses.
This separation of concerns is a win-win in my book as it allows both scripts to be developed, tested and used independently, and also provides uncomplicated multi-tasking that ensures the GUI remains responsive without affecting the performance, or complicating the construction, of the CLI script that does the work.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
|