Implicit initialization is EVIL!
rosuav at gmail.com
Tue Jul 5 20:34:08 EDT 2011
On Wed, Jul 6, 2011 at 10:15 AM, rantingrick <rantingrick at gmail.com> wrote:
> On Jul 5, 6:54 pm, Chris Angelico <ros... at gmail.com> wrote:
>> To do what for me? Close windows? Reclaim memory? Terminate
>> applications? I don't understand your bogglement.
> ClaimA: I made claim that Tkinter's window hierarchy is not only
> normal, but justified in modern GUI programming.
> ClaimB: You made a claim ( or supported a rebuttal claim) that Mac's
> system of window management was superior and did not need such a
> "window hierarchy" simply because;
I never said "better". I just said that it's possible to create an
application that *to the user* has no main window, even though *to the
system* it does. And I'm also pointing out that in most good toolkits,
there's no "main window", but instead a "main thread".
> 1. You can create a program that twiddles it's thumbs (using very
> little memory) until a message is received.
> 2. Upon receiving a message the program can open a GUI window.
> 3. When the user closes the GUI window (definition of "close" is not
> nailed down yet!) the program will free the GUI memory and start
> twiddling it's thumbs again until the next message arrives.
> 4. rinse and repeat until you are happy.
Again, pointing out that it's possible, not that it's good. (Most
messenger programs will have a means of *sending* messages too, which
makes a good basis for a main window.) It's not efficient to keep
loading up GUI libraries and discarding them again. But it's possible,
and it would mean that you genuinely have multiple equal main windows.
> It's obvious that yours and my claims are contradicting. So with that
> said, at what point does Tkinter or Windows fail in this example you
> provide? Because, i can recreate the exact same functionality on a
> windows box without need of the underlying window manager's help.
Actually, everything you do requires the underlying window manager,
otherwise you're just painting your own pixels on the screen. And I
never said that this model was possible in some and not others.
(Although it's a bit harder with Windows; there's no explicit call to
finalize windowing, so most likely the application will hold GUI
memory until termination.)
More information about the Python-list