Implicit initialization is EVIL!

[rantingrick]

On Jul 7, 12:34 am, Gregory Ewing <greg.ew... at 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*