note that this is different from using nested (recursivemainloop calls to implement modal dialogsas we did in in that modethe nested mainloop call returns when the dialog' quit method is calledbut we return to the enclosing mainloop layer and remain in the realm of event-driven programming example - instead runs mainloop two different timesstepping into and out of the event-driven model twice finallynote that this scheme works only if you don' have to run any non-gui code while the gui is openbecause your script' mainline code is inactive and blocked while mainloop runs you cannotfor exampleapply this technique to use utilities like those in the guistreams module we met earlier in this to route user interaction from non-gui code to gui windows the guiinput and guioutput classes in that example assume that there is mainloop call running somewhere (they're gui-basedafter allbut once you call mainloop to pop up these windowsyou can' return to your non-gui code to interact with the user or the gui until the gui is closed and the mainloop call returns the net effect is that these classes can be used only in the context of fully gui program but reallythis is an artificial way to use tkinter example - works only because the gui can interact with the user independentlywhile the mainloop call runsthe script is able to surrender control to the tkinter mainloop call and wait for results that scheme won' work if you must run any non-gui code while the gui is open because of such constraintsyou will generally need main-window-plus-callbacks model in most gui programs--callback code runs in response to user interaction while the gui remains open that wayyour code can run while gui windows are active for an examplesee earlier in this for the way the non-gui packer and unpacker scripts were run from gui so that their results appear in guitechnicallythese scripts are run in gui callback handler so that their output can be routed to widget adding gui as separate programsockets ( second lookas mentioned earlierit' also possible to spawn the gui part of your application as completely separate program this is more advanced techniquebut it can make integration simple for some applications because of the loose coupling it implies it canfor instancehelp with the guistreams issues of the prior sectionas long as inputs and outputs are communicated to the gui over inter-process communication (ipcmore ways to add guis to non-gui code