I am an electrical engineer building a Python application to interface with PSS/E (Power Systems Simulation for Engineers by PTI Siemens). The way the code currently works, the program contains a main method which calls methods from two classes (in separate files) which I have written. Throughout the different steps of the program, the user interacts with it through a terminal (Enter file paths, press enter to continue, etc).
I am working on implementing a GUI with Tkinter. The user would browse to select several files, select certain options, then press 'Start'. Then, the user would interact with the GUI at the different steps of the program, instead of typing into the terminal.
What would be the philosophy used to implement a GUI into this program? I am thinking that on the one hand, I can have a file for the GUI, initiate the program from this file, then call the main method when the user pushes 'start'. The options/file paths from the user, would be passed to the main method as parameters. On the other hand, I'm thinking of integrating the GUI into my main method. Have a separate file with the class/methods for the Tkinter widgets, and call them from main as needed. Which (if any) of these would be the best way to go, and why? I also have a question about how to deal with Python 2.7 being 'retired' in January of 2020, since my code is dependent on version 2.7. I will ask this in another question to allow for some elaboration on this GUI question. Thanks in advance for your input.
While it is possible to write a GUI program as a straight port of a terminal program that works as you describe, with the main program driving the flow of interaction with the user, most GUI programs are written as a set of event handlers, also called callback functions. Because the event loop is calling back to you using the handlers you provide to it.
Usually the main program just declares your controls, binds them to handlers, and starts the event handling loop.
There are various ways to organize such a program, and it depends a lot on your workflow.
But the event handling functions usually drive the overall logic, rather than the main program. This allows the user to interact with your program in a less linear way.
It is often useful to decouple the event handling logic and create a 'model' that represents the state of your program and logic unrelated to the GUI. Then the event handlers would call functions or methods of your model to change the state of the program.