On Jul 7, 12:34 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > rantingrick wrote: > > Yes but what benefit does that gain over say, Tkinter's design > > (because that has been your argument). > > Like I said, it's a tangential issue.
Agreed. > The important thing is that it's okay for an app to stay > alive until its *last* top level window is closed. So your argument is: """ A window hierarchy is bad because if your application requires a user to open a gazillion windows (read as: designed poorly) --each representing completely different transactions-- and if you close the original window all the "other" windows will close too. Boo :(""" continuing... > There > doesn't have to be a special "main" window that kills the > whole app when you close it. So you prefer to close a gazillion windows one by one? If so, why not just code the GUI correctly from the start; by creating separate transactions? Thereby reducing the number of windows a user must juggle? FYI: You know the user complexity of a GUI increases exponentially by the number of windows present. > However, I think what the original complaint was really > about is that when you create a non-toplevel widget in Tkinter > you have to specify its parent (and if you don't, it assumes > you want it to be a child of the main window). Thats was MY complaint yes. On the grounds that widgets require windows NOT windows require widgets. This fact will confuse folks. > You can't > create the widget first and specify its parent later. > > This is another API flaw that is seen distressingly often > in GUI libraries. It's a nuisance, because it means you can't > write code that creates a widget hierarchy bottom-up. Actually you can! Stay tuned for enlightenment! > For > example, in PyGUI you can write things like > dialog_contents = Column([ > Label("Caution: Your underpants are on fire."), > Row([Button("OK"), Button("Cancel")]) > ]) > > There's no way you could write Row and Column functions for > Tkinter that work like that -- they would have to take parent > widgets as arguments, and you wouldn't be able to nest the > calls. WRONG! A function or class structure can handle this just fine. And lends itself nicely to GUI programming. ## START CODE ## import Tkinter as tk class DumbDialog(tk.Toplevel): def __init__(self, master, **kw): w=tk.Label(master, text="Caution: Your underpants are on fire.") w.pack() w=tk.Button(master, text="OK").pack() w=tk.Button(master, text="Cancel").pack() print 'start script' root = tk.Tk() d = DumbDialog(root) root.mainloop() print 'continue script' root = tk.Tk() d = DumbDialog(root) root.mainloop() print 'end script' ## END CODE ## *school bell rings* -- http://mail.python.org/mailman/listinfo/python-list