FAQ
Tkinter has a major flaw and this flaw has been with us for many many
years. What is the flaw? Well the title says it all folks... IMPLICIT
INITIALIZATION IS EVIL. Still confused, well let me explain.

Unlike most GUI libraries the Tkinter developers thought is would
"just wonderful" if the root GUI window just sprang into existence if
the programmer "somehow" forgot to create one. Does anyone remember
the old adage...

""" The road to hell is paved with good intentions? """

...as you're about to see this road is paved in gold around thee
parts! You're probably thinking to yourself that i am stretching the
truth for the sake of drama? Well i wish i could answer yes, but i
cannot. So without further "a due" let me show you some code...

## START CODE ##
from Tkinter import *
label = Label(parent=None, text='This is an example of poor GUI
design!')
label.pack()
label.mainloop()
## END CODE ##

As you can see the root window is auto created for the caller and this
sort of hand holding only served to confuse the hell of out new folks!
Sure it's "cute" (and all that type of nifty swiftly crap!) but it is
EVIL! A new user should learn from day one the hierarchy of a GUI.

-root window
-optional widgets
--optional sub windows
---optional widgets
---and on and on

root = Tk() # Or a derived class of Tk
frame = Frame(root)
w = Widget(frame)
and on and on and on

We should never propagate this sort of confusion throughout our
community. Please remove this dangerous design pattern immediately.

Search Discussions

  • Chris Angelico at Jul 3, 2011 at 10:21 pm

    On Mon, Jul 4, 2011 at 8:11 AM, rantingrick wrote:
    A new user should learn from day one the hierarchy of a GUI.

    -root window
    -optional widgets
    --optional sub windows
    ---optional widgets
    ---and on and on
    You're forgetting all the other crucial parts of the hierarchy. A new
    user should be forced to declare a Desktop that s/he wants the window
    on, and a Screen, and choose which video driver to use too! Implicit
    acceptance of defaults is EVIL! Oh, and while you're at it, Python's
    habit of letting you skip variable declarations is EVIL too. A new
    user should learn from day one that variables need to be stored
    somewhere, so Python should stop coddling its newbies and actually get
    them to do things right:

    var(0x14205359) x # Don't forget to provide an address where the
    object will be located
    xB

    After all, everyone's gotta learn about segfaults some day!

    Chris Angelico
  • Robin Becker at Jul 4, 2011 at 3:35 pm
    On 03/07/2011 23:21, Chris Angelico wrote:
    .........
    var(0x14205359) x # Don't forget to provide an address where the
    object will be located
    xB
    ........
    did you forget to specify the memory bank and computer (and presumably planet
    etc etc....)
    -molly-coddled-ly yrs-
    Robin Becker
  • Nn at Jul 5, 2011 at 3:33 pm

    On Jul 4, 11:35?am, Robin Becker wrote:
    On 03/07/2011 23:21, Chris Angelico wrote:
    .........
    var(0x14205359) x ? # Don't forget to provide an address where the
    object will be located
    xB
    ........
    did you forget to specify the memory bank and computer (and presumably planet
    etc etc....)
    -molly-coddled-ly yrs-
    Robin Becker
    Ah, I see we have a mainframe programmer among us ... :-)
  • Robin Becker at Jul 5, 2011 at 4:23 pm
    On 05/07/2011 16:33, nn wrote:
    ......
    Ah, I see we have a mainframe programmer among us ... :-)
    so long since I manipulated the switches of that old pdp-8
    -anciently yrs-
    Robin Becker
  • Roy Smith at Jul 3, 2011 at 10:32 pm
    In article <mailman.588.1309731711.1164.python-list at python.org>,
    Chris Angelico wrote:
    var(0x14205359) x # Don't forget to provide an address where the
    object will be located
    xB

    After all, everyone's gotta learn about segfaults some day!
    0x14205359 is more likely to give a bus error (odd address) than a
    segfault :-)
  • Gregory Ewing at Jul 4, 2011 at 8:33 am

    rantingrick wrote:

    Unlike most GUI libraries the Tkinter developers thought is would
    "just wonderful" if the root GUI window just sprang into existence if
    the programmer "somehow" forgot to create one.
    IMO the real problem here is the existence of a privileged
    "root" window at all. No GUI platform I know of has any
    such concept (except for a "desktop" window that represents
    the whole screen, which is not the same thing). All top-level
    windows should have equal status.

    --
    Greg
  • Chris Angelico at Jul 4, 2011 at 8:44 am

    On Mon, Jul 4, 2011 at 6:33 PM, Gregory Ewing wrote:
    rantingrick wrote:
    Unlike most GUI libraries the Tkinter developers thought is would
    "just wonderful" if the root GUI window just sprang into existence if
    the programmer "somehow" forgot to create one.
    IMO the real problem here is the existence of a privileged
    "root" window at all. No GUI platform I know of has any
    such concept (except for a "desktop" window that represents
    the whole screen, which is not the same thing). All top-level
    windows should have equal status.
    I don't know Tkinter, but from the look of the example code, he's
    creating a Label that's not attached to a window, and then packing it
    into nothing. The toolkit kindly creates him a window. Is that the
    "root GUI window" that he means? A basic top-level window?

    Chris Angelico
  • Rantingrick at Jul 4, 2011 at 3:19 pm

    On Jul 4, 3:33?am, Gregory Ewing wrote:

    IMO the real problem here is the existence of a privileged
    "root" window at all. No GUI platform I know of has any
    such concept (except for a "desktop" window that represents
    the whole screen, which is not the same thing). All top-level
    windows should have equal status.

    I dunno, it's natural to create a parent-child hierarchy when GUI
    programming with any library. So i am not completely sure what you are
    implying here? When you close the main application widow you would
    expect all child windows to close. Or likewise when you iconify the
    main window you would expect the other windows to do the same. Sure
    you could do this yourself by sending messages to all the other
    windows but Tkinter does this for you automatically. And how does
    Tkinter know which windows to configure? A parent-child relationship
    that's how.
    a = set(dir(Tkinter.Toplevel))
    b = set(dir(Tkinter.Tk))
    len(a), len(b)
    (222, 226)
    a.difference(b)
    set(['_setup', '_do'])

    You say "root" windows are bad however any parent-child relationship
    has to BEGIN somewhere. For Tkinter the beginning of this dynasty is
    an instance of the Tkinter.Tk[1] window from which all other windows
    and widgets are made children. HOWEVER any of the windows ARE in fact
    instances of Tk.Toplevel[1]. So they ARE all equal because they all
    have the same methods available to them.
    import Tkinter
    Tkinter.Tk.__doc__
    'Toplevel widget of Tk which represents mostly the main window\n of
    an appliation. It has an associated Tcl interpreter.'
    import inspect
    inspect.getmro(Tkinter.Tk)
    (<class Tkinter.Tk at 0x02742210>, <class Tkinter.Misc at 0x02742570>,
    <class Tkinter.Wm at 0x0272F780>)
    inspect.getmro(Tkinter.Toplevel)
    (<class Tkinter.Toplevel at 0x02742690>, <class Tkinter.BaseWidget at
    0x02742630>, <class Tkinter.Misc at 0x02742570>, <class Tkinter.Wm at
    0x0272F780>)

    But let's dig a little deeper here. Your comment suggests that you
    "personally" need to create multiple windows for your applications. Is
    this correct? If so i pity any users of such application as they would
    be thoroughly confused. Most applications consist of one main window
    (a Tkinter.Tk instance). The only need for extra Toplevel windows is
    in the form of modal dialogs (use tkSimpleDialog.Dialog) or tool
    windows (use Tk.Toplevel with attribute '-toolwindow'=True).

    I don't see how your statements carry any weight here. Could you
    explain please?

    [1] http://effbot.org/tkinterbook/tkinter-application-windows.htm
    [2] http://effbot.org/tkinterbook/toplevel.htm
  • Chris Angelico at Jul 4, 2011 at 3:40 pm

    On Tue, Jul 5, 2011 at 1:19 AM, rantingrick wrote:
    But let's dig a little deeper here. Your comment suggests that you
    "personally" need to create multiple windows for your applications. Is
    this correct? If so i pity any users of such application as they would
    be thoroughly confused. Most applications consist of one main window
    (a Tkinter.Tk instance). The only need for extra Toplevel windows is
    in the form of modal dialogs (use tkSimpleDialog.Dialog) or tool
    windows (use Tk.Toplevel with attribute '-toolwindow'=True).
    Uhh, sorry. No. There are plenty of good reasons for one application
    to make multiple top-level windows, and if I ever find myself using a
    toolkit that makes this difficult, I'll either be hacking the toolkit
    or using a different one. I've been building GUI applications for far
    too long to not want features like that.

    ChrisA
  • Rantingrick at Jul 4, 2011 at 3:45 pm
    oops. should have used symmetric_difference!
    a.symmetric_difference(b)
    set(['_w', '_setup', 'report_callback_exception', '_do',
    '__getattr__', 'loadtk', '_loadtk', 'readprofile'])
  • Rantingrick at Jul 4, 2011 at 3:46 pm

    On Jul 4, 10:40?am, Chris Angelico wrote:

    Uhh, sorry. No. There are plenty of good reasons for one application
    to make multiple top-level windows, and if I ever find myself using a
    toolkit that makes this difficult, I'll either be hacking the toolkit
    or using a different one. I've been building GUI applications for far
    too long to not want features like that.
    And those reasons are...?
  • Chris Angelico at Jul 4, 2011 at 4:01 pm

    On Tue, Jul 5, 2011 at 1:46 AM, rantingrick wrote:
    On Jul 4, 10:40?am, Chris Angelico wrote:

    Uhh, sorry. No. There are plenty of good reasons for one application
    to make multiple top-level windows, and if I ever find myself using a
    toolkit that makes this difficult, I'll either be hacking the toolkit
    or using a different one. I've been building GUI applications for far
    too long to not want features like that.
    And those reasons are...?
    As varied as the applications that call on them. One example that
    springs to mind: Our database front end has "table view" and "record
    view", where you get one table view and from that you can view as many
    records as you like. Users may choose to effectively switch from one
    view to the other, or they may open up two or more record views and
    have them and the table view all on screen simultaneously. This is not
    a modal dialog; it's not even a modeless dialog - it's a completely
    stand-alone window that can be moved around the Z order independently
    of the parent. There's a definite ownership based on process, though;
    terminate the process (by closing the table view) and it must close
    all record views first. I've done other applications where this has
    not been the case - where all top-level windows are truly equal - but
    not in this instance.

    As an aside, that particular program is one that we are currently
    using (I glance over and can see it running on one of our terminals
    here), and the interface has not changed since about 2002 (actually
    earlier - 2002 had a major code rewrite without much UI change).
    Multiple top-level windows fulfills the Law of Least Astonishment
    admirably, and has done so for a decade.

    Chris Angelico
  • Rantingrick at Jul 4, 2011 at 5:09 pm

    On Jul 4, 11:01?am, Chris Angelico wrote:
    On Tue, Jul 5, 2011 at 1:46 AM, rantingrick wrote:
    On Jul 4, 10:40?am, Chris Angelico wrote:

    Uhh, sorry. No. There are plenty of good reasons for one application
    to make multiple top-level windows, and if I ever find myself using a
    toolkit that makes this difficult, I'll either be hacking the toolkit
    or using a different one. I've been building GUI applications for far
    too long to not want features like that.
    And those reasons are...?
    As varied as the applications that call on them. One example that
    springs to mind: Our database front end has "table view" and "record
    view", where you get one table view and from that you can view as many
    records as you like. Users may choose to effectively switch from one
    view to the other, or they may open up two or more record views and
    have them and the table view all on screen simultaneously.
    This is not
    a modal dialog; it's not even a modeless dialog - it's a completely
    stand-alone window that can be moved around the Z order independently
    of the parent.
    You can do the exact same thing with Tkinter's windows.
    There's a definite ownership based on process, though;
    terminate the process (by closing the table view) and it must close
    all record views first. I've done other applications where this has
    not been the case - where all top-level windows are truly equal - but
    not in this instance.
    Tkinters Toplevels ARE equal!

    However in this case you should spawn a new instance of the
    application "opened" at that particular table view. It's as simple as
    a few command line arguments in your script.

    It's like a text editor, you never want a "New" command that resets
    the current document or an open command that resets the current
    document and loads the file into the existing editor. Each application
    instance should only create one document and stick with it until it is
    closed.

    Instead you want to spawn a new instance of the editor and tell the
    editor (via command line arguments) to load file data (if applicable).
    Simple command line arguments (of which you should be using anyway)
    are the key here. All part of proper software design.
  • Chris Angelico at Jul 4, 2011 at 5:41 pm

    On Tue, Jul 5, 2011 at 3:09 AM, rantingrick wrote:
    On Jul 4, 11:01?am, Chris Angelico wrote:
    This is not
    a modal dialog; it's not even a modeless dialog - it's a completely
    stand-alone window that can be moved around the Z order independently
    of the parent.
    You can do the exact same thing with Tkinter's windows.
    I didn't say Tkinter couldn't do this; I said that it was a good thing
    to be able to do, which you earlier decried.
    However in this case you should spawn a new instance of the
    application "opened" at that particular table view. It's as simple as
    a few command line arguments in your script.
    No! Definitely not. Initializing the application includes logging in
    to the database. Suppose the user had to log in again... or, worse,
    suppose I transmitted the username and password via command line
    arguments. No, forcing programmers into a particular coding model is a
    bad idea. Let the individual programmer decide what tool is best for
    what job.
    It's like a text editor, you never want a "New" command that resets
    the current document or an open command that resets the current
    document and loads the file into the existing editor. Each application
    instance should only create one document and stick with it until it is
    closed.
    What, never? Well, hardly ever! (As per HMS Pinafore, if you're wondering.)

    Actually, I quite frequently do want exactly that. Replace the current
    buffer with a new document. Keeping the previous document involves one
    of two choices (maybe more, but I can't think of any off hand):

    * Leave the other document visible on the screen, cluttering things up
    and forcing the user to switch to the other window, close it, and then
    return to his work; or
    * Have the new window completely and exactly mask the old one, making
    it unobvious that the previous document is actually still open,
    leaving enormous possibilities for confusion.

    Audacity takes the first option (at least, the Windows version that I
    used five years ago did). You choose New or Open, it brings up another
    window. This astonished me when I first saw it (strike one), annoys me
    85% of the time and is useful only 15% (strike two), and tends to get
    in the way of rapid keyboard-oriented navigation (strike three and
    out). I'd much rather Audacity kept all its "stuff" in one window,
    unless I explicitly asked it for another window.

    For another example, look at where web browsers are going. By your
    description, one instance of a browser should work with precisely one
    "document" (which in this case would be a web page). That's how
    browsers were in the early days, but by the early 2000s most browsers
    had some form of tabs, letting you keep that application in one
    window.
    Instead you want to spawn a new instance of the editor and tell the
    editor (via command line arguments) to load file data (if applicable).
    Simple command line arguments (of which you should be using anyway)
    are the key here. All part of proper software design.
    Of course I could spawn a new instance. But why? Why do it? And if I
    have to have a completely new copy of all the editor's state, this is
    hopelessly inefficient on memory and startup work. Why should
    File|Open incur such a cost? (Ameliorated if you fork() but that has
    its own consequences.) But the memory cost is nothing compared to the
    extra interference it puts on "mindspace".

    I currently have precisely two slots in mindspace for web browsers:
    Chrome and Firefox. Chrome currently has about a dozen tabs up;
    Firefox about the same, but most of them are long-term status reports
    that I keep handy. If I had to have 20-30 separate windows, I would
    not be able to use alt-tab to find the one I want, but would have to
    use some other kind of "window picker". How would you write a
    user-friendly picker that can cope with myriad instances of
    everything? My guess is that it'd use some kind of tree structure with
    applications at one level and windows at the next. Is this not exactly
    what we already have?

    Chris Angelico
  • Rantingrick at Jul 4, 2011 at 7:30 pm

    On Jul 4, 12:41?pm, Chris Angelico wrote:

    For another example, look at where web browsers are going. By your
    description, one instance of a browser should work with precisely one
    "document" (which in this case would be a web page). That's how
    browsers were in the early days, but by the early 2000s most browsers
    had some form of tabs, letting you keep that application in one
    window.
    Umm, if you want to see where things are "going" you should learn
    about the inner workings of chrome which actually spawns a new process
    for every tab created; which has the benefit of avoiding application
    lock up when one page decides to crash.
    I currently have precisely two slots in mindspace for web browsers:
    Chrome and Firefox. Chrome currently has about a dozen tabs up;
    Firefox about the same, but most of them are long-term status reports
    that I keep handy. If I had to have 20-30 separate windows, I would
    not be able to use alt-tab to find the one I want, but would have to
    use some other kind of "window picker". How would you write a
    user-friendly picker that can cope with myriad instances of
    everything?
    psst: it's called a notebook in GUI jargon. Again, study up on chrome
    internals.
  • Chris Angelico at Jul 4, 2011 at 9:43 pm

    On Tue, Jul 5, 2011 at 5:30 AM, rantingrick wrote:
    Umm, if you want to see where things are "going" you should learn
    about the inner workings of chrome which actually spawns a new process
    for every tab created; which has the benefit of avoiding application
    lock up when one page decides to crash.
    There is still one application. There's a single process which is the
    master; all the other processes die if the master dies. Chrome's
    isolation of tab-groups has nothing to do with the GUI design question
    of whether one top-level window is allowed to do more than one thing,
    which you claimed it should not.
    How would you write a
    user-friendly picker that can cope with myriad instances of
    everything?
    psst: it's called a notebook in GUI jargon. Again, study up on chrome
    internals.
    No, that would not be what it would be called. Also, a notebook is a
    very specific widget, and it's not quite identical to Chrome's or
    Firefox's tabbed browsing setup; but again, that has nothing to do
    with the case. The question is one of UI design.

    ChrisA
  • Gregory Ewing at Jul 5, 2011 at 11:11 am

    rantingrick wrote:

    You say "root" windows are bad however any parent-child relationship
    has to BEGIN somewhere.
    There's no need for *toplevel* windows to be children
    of anything, though.
    HOWEVER any of the windows ARE in fact
    instances of Tk.Toplevel[1]. So they ARE all equal because they all
    have the same methods available to them.
    No, they're not -- the root window is special, because
    if you kill it, the whole application exits. Often that
    is inconvenient.

    --
    Greg
  • Gregory Ewing at Jul 5, 2011 at 11:14 am

    rantingrick wrote:
    Most applications consist of one main window
    (a Tkinter.Tk instance).
    You've obviously never used a Macintosh. On the Mac, it's
    perfectly normal for an application to open multiple
    documents, each in its own window, with no one window
    being the "main" window. Any of them can be closed (or
    even *all* of them) and the application continues to run
    until you explicitly quit it.

    --
    Greg
  • Steven D'Aprano at Jul 5, 2011 at 2:25 pm

    Gregory Ewing wrote:

    rantingrick wrote:
    Most applications consist of one main window
    (a Tkinter.Tk instance).
    You've obviously never used a Macintosh. On the Mac, it's
    perfectly normal for an application to open multiple
    documents, each in its own window, with no one window
    being the "main" window. Any of them can be closed (or
    even *all* of them) and the application continues to run
    until you explicitly quit it.
    Or a Linux GUI. I have kwrite running with 15 open windows. The application
    doesn't exit until the last window is closed, and no window is privileged
    over the others.

    Even in Windows, the sort of MDI interface Rick seems to be describing is
    less common now than it used to be -- possibly even rare.

    http://en.wikipedia.org/wiki/Multiple_document_interface


    --
    Steven
  • Chris Angelico at Jul 5, 2011 at 3:17 pm

    On Wed, Jul 6, 2011 at 12:25 AM, Steven D'Aprano wrote:
    Gregory Ewing wrote:
    You've obviously never used a Macintosh. On the Mac, it's
    perfectly normal for an application to open multiple
    documents, each in its own window, with no one window
    being the "main" window. Any of them can be closed (or
    even *all* of them) and the application continues to run
    until you explicitly quit it.
    Or a Linux GUI. I have kwrite running with 15 open windows. The application
    doesn't exit until the last window is closed, and no window is privileged
    over the others.
    It's actually quite easy to implement this, even if you _are_ forced
    to have one primary window. You just have an invisible primary whose
    sole purpose is to "be the application", and then everything else is
    secondary windows. Kinda defeats the purpose of forcing applications
    to have one primary window, though.

    To my thinking, there will always be one primary *thread*, and GUI
    facilities are secondary to the process, never the other way around.
    When the main thread exits, the process ends.

    ChrisA
  • Rantingrick at Jul 5, 2011 at 10:38 pm

    On Jul 5, 10:17?am, Chris Angelico wrote:

    It's actually quite easy to implement this, even if you _are_ forced
    to have one primary window. You just have an invisible primary whose
    sole purpose is to "be the application", and then everything else is
    secondary windows. Kinda defeats the purpose of forcing applications
    to have one primary window, though.

    To my thinking, there will always be one primary *thread*, and GUI
    facilities are secondary to the process, never the other way around.
    When the main thread exits, the process ends.

    Chris are you playing devils advocate (for my team). I am confused? :-)
  • Rantingrick at Jul 5, 2011 at 10:42 pm

    On Jul 5, 11:00?am, Web Dreamer wrote:

    What he means is that On Mac, if you close "all" windows, the application is
    still running.
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    Let's use the correct lingo people!
  • Chris Angelico at Jul 5, 2011 at 11:20 pm

    On Wed, Jul 6, 2011 at 8:42 AM, rantingrick wrote:
    Chris are you playing devils advocate (for my team). I am confused? :-)
    I say whatever I choose to say. Don't pigeon-hole me into "on your
    team" or "not on your team" or "devil's advocate" or whatever. And at
    two in the morning, "whatever I choose to say" can be quite random. :)
    On Jul 5, 11:00?am, Web Dreamer wrote:

    What he means is that On Mac, if you close "all" windows, the application is
    still running.
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    Let's use the correct lingo people!
    Actually, it IS closing those windows. Why wouldn't it be?

    1) User presses Alt-F4, or clicks the X, or opens the system menu and
    chooses 'Close Window'.
    2) Windowing manager sends a message to the appropriate thread's queue
    (on MS Windows, that's WM_CLOSE; not sure how on Linux as I haven't
    bothered to dig that deep - interface layers like Tkinter and GTK
    don't count).
    2a) Toolkit passes message to application code, if applicable.
    3) Application destroys this window, leaving the other windows alive.

    The memory used by that window can be reclaimed. Handles to its
    objects are no longer valid. The window really is closed. The
    application might not have terminated, but that window has not been
    minimized - the *window* is closed.
    And how do you EXPLICITY quit the application? Because the interface
    for window management(on windows box) is three buttons "minimize",
    "maximize", and "destroy". If closing the window only "hides" the
    window then you are just "managing" a window's "visibility". We are
    talking about destroying GUI processes here.
    Presumably you would right-click it and choose "Exit" or something. Up
    to the application. If all else fails, kill -9 it.

    The interface for window management does not actually have "destroy",
    it has "close". The normal handling of a close message is to destroy
    the window; and in many applications, once all windows have been
    destroyed, the process terminates. These are three quite separate
    concepts. The separation of "close" and "destroy" is most easily seen
    in "Are you sure" prompts - you send a Close signal to the window, but
    the application queries you before going through with the destruction.
    And even once the last window has been destroyed, that has nothing to
    do with process termination.

    I could conceivably write a program that sits invisibly in the
    background until a network message arrives. Upon receipt of such a
    message, the program initializes the GUI subsystem and opens a window.
    When the user closes the window, the program flushes all GUI code out
    of memory and waits for the next message. While it's waiting, is there
    any "main window" that exists but has just been hidden? No. But is the
    application still running? Of course! Completely separate.

    ChrisA
  • Rantingrick at Jul 5, 2011 at 11:47 pm

    On Jul 5, 6:20?pm, Chris Angelico wrote:
    On Wed, Jul 6, 2011 at 8:42 AM, rantingrick wrote:
    [...]
    On Jul 5, 11:00?am, Web Dreamer wrote:
    What he means is that On Mac, if you close "all" windows, the application is
    still running.
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    Let's use the correct lingo people!
    Actually, it IS closing those windows. Why wouldn't it be?
    [...]
    The memory used by that window can be reclaimed. Handles to its
    objects are no longer valid. The window really is closed. The
    application might not have terminated, but that window has not been
    minimized - the *window* is closed.
    And you need the OS to that for you!?!? Are you joking?
    I could conceivably write a program that sits invisibly in the
    background until a network message arrives. Upon receipt of such a
    message, the program initializes the GUI subsystem and opens a window.
    When the user closes the window, the program flushes all GUI code out
    of memory and waits for the next message. While it's waiting, is there
    any "main window" that exists but has just been hidden? No. But is the
    application still running? Of course! Completely separate.
    And so could i using Tkinter and it's "supposedly" flawed window
    hierarchy. Remind me again why we are discussing this?
  • Chris Angelico at Jul 5, 2011 at 11:54 pm

    On Wed, Jul 6, 2011 at 9:47 AM, rantingrick wrote:
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    Let's use the correct lingo people!
    Actually, it IS closing those windows. Why wouldn't it be?
    [...]
    The memory used by that window can be reclaimed. Handles to its
    objects are no longer valid. The window really is closed. The
    application might not have terminated, but that window has not been
    minimized - the *window* is closed.
    And you need the OS to that for you!?!? Are you joking?
    To do what for me? Close windows? Reclaim memory? Terminate
    applications? I don't understand your bogglement.

    ChrisA
  • Rantingrick at Jul 6, 2011 at 12:15 am

    On Jul 5, 6:54?pm, Chris Angelico 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;

    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.

    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.

    1. What is your point?
    2. And how does it prove my position incorrect?
  • Chris Angelico at Jul 6, 2011 at 12:34 am

    On Wed, Jul 6, 2011 at 10:15 AM, rantingrick wrote:
    On Jul 5, 6:54?pm, Chris Angelico 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.)

    ChrisA
  • Rantingrick at Jul 6, 2011 at 1:10 am

    On Jul 5, 7:34?pm, Chris Angelico wrote:

    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.)
    Ah ha. I think we are getting somewhere now. Everything up to this
    point has been mostly exposition :-)
  • Gregory Ewing at Jul 6, 2011 at 6:12 am

    rantingrick wrote:

    What he means is that On Mac, if you close "all" windows, the application is
    still running.
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    No, the windows really are closed. They no longer exist
    in any way. The application is still running, though, and
    its menu bar will appear if you bring it to the front
    (in MacOSX this is done by clicking on its dock icon;
    in classic MacOS it was done by selecting from the menu
    of running applications that was available in the top right
    corner of the screen).

    --
    Greg
  • Rantingrick at Jul 6, 2011 at 1:51 pm

    On Jul 6, 1:12?am, Gregory Ewing wrote:
    rantingrick wrote:
    What he means is that On Mac, if you close "all" windows, the application is
    still running.
    Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
    No, the windows really are closed. They no longer exist
    in any way. The application is still running, though, and
    its menu bar will appear if you bring it to the front
    (in MacOSX this is done by clicking on its dock icon;
    in classic MacOS it was done by selecting from the menu
    of running applications that was available in the top right
    corner of the screen).
    Yes but what benefit does that gain over say, Tkinter's design
    (because that has been your argument). I see no benefit at all. I can
    destroy a GUI and still have a script run, but what's the point?

    If you design a GRAPHICAL user interface, then once the GRAPHICAL part
    is removed (window), why do need the main code to stick around? And if
    you do, that fact has nothing to do with Tkinter and window hierarchy.
    I think we've gone completely off topic here.

    Is this another community strawman contest?
    Are we mass producing these things now?
  • Steven D'Aprano at Jul 6, 2011 at 2:32 pm

    rantingrick wrote:

    If you design a GRAPHICAL user interface, then once the GRAPHICAL part
    is removed (window), why do need the main code to stick around?
    Open your mind to ideas that go beyond your simple window-centric paradigm!
    There is more to graphical user interfaces than windows!

    In the Mac OS GUI, an application can have a menubar and no windows. Windows
    come and go as needed, but the menubar stays until the users quits the
    application.

    In the Unix/Linux world, there is a graphical application called xkill which
    has no menus and no windows, all it has is a mouse cursor! No, it does not
    run in the background: it is a foreground app.

    An extreme case, but telling. There is no absolute need for any windows at
    all, let alone for one privileged window to rule all the others.


    --
    Steven
  • Rantingrick at Jul 6, 2011 at 3:10 pm

    On Jul 6, 9:32?am, Steven D'Aprano <steve +comp.lang.pyt... at pearwood.info> wrote:
    rantingrick wrote:
    If you design a GRAPHICAL user interface, then once the GRAPHICAL part
    is removed (window), why do need the main code to stick around?
    Open your mind to ideas that go beyond your simple window-centric paradigm!
    Correction: Window-Centric GUI paradigm! BIG DIFFERENCE.
    There is more to graphical user interfaces than windows!
    OMG, you mean like, widgets? Whoa! Tell me more, Tell me more!
    In the Mac OS GUI, an application can have a menubar and no windows. Windows
    come and go as needed, but the menubar stays until the users quits the
    application.
    That's just window visibility (whether by hiding or destroying) under
    the veil of a detached UI window manager bar and has nothing to do
    with window hierarchy. Your half stuffed straw men are leaking like a
    sieve Steven.
    In the Unix/Linux world, there is a graphical application called xkill which
    has no menus and no windows, all it has is a mouse cursor! No, it does not
    run in the background: it is a foreground app.
    Wow nice corner case. Can you come up with at least five of them
    though? You and I both know that the vast majority of GUI's require
    visible windows.

    But wait! What is a GUI WINDOW exactly?

    I'll tell you in the simplest terms i can muster... GUI "windows" are
    an abstraction and nothing more. A GUI window is nothing more than an
    imaginary area of the screen that can be drawn to. This area has
    borders that define it. No not visible borders but two dimensional
    spacial borders. THAT'S IT! The area could be 1x1 pixels OR the entire
    screen space, OR even larger!

    Most time you want the user to see the boundaries of this abstraction
    (window) space and so the GUI library draws borders that represent
    this boundary. Your "supposedly" windowless xkill application is not
    windowless at all; THE WINDOW BOUNDARIES ARE JUST NOT DRAWN! The
    window is the entire screen space OR IS JUST THE DESKTOP SPACE (same
    thing)
    An extreme case, but telling. There is no absolute need for any windows at
    all, let alone for one privileged window to rule all the others.
    Again your fear of losing "imaginary" freedoms is acting out again.
    And your veiled attempts to link root GUI windows and Sauron (the
    great antagonist of LOTH) is quite entertaining. Next you'll suggest
    that root windows are really just a great eye, lidless, and wreathed
    in flame and that i am Saruman building an army of Orc followers hell
    bent on destroying the freedom to believe self serving fantasies.
  • Steven D'Aprano at Jul 6, 2011 at 4:11 pm

    rantingrick wrote:

    In the Mac OS GUI, an application can have a menubar and no windows.
    Windows come and go as needed, but the menubar stays until the users
    quits the application.
    That's just window visibility (whether by hiding or destroying) under
    the veil of a detached UI window manager bar and has nothing to do
    with window hierarchy.
    If all the windows are destroyed, and the application still is running and
    active, where is your window hierarchy?



    The Dead Window Sketch
    ======================

    (with apologies to Monty Python)

    Customer enters a pet shop.
    Customer: 'Ello, I wish to register a complaint.
    Owner: We're closin' for lunch.
    Customer: Never mind that, my lad. I wish to complain about this GUI
    window what I purchased not half an hour ago from this very
    boutique.
    Owner: Oh yes, the Norwegian Blue. What's wrong with it?
    Customer: I'll tell you what's wrong with it, my lad. It's deleted,
    that's what's wrong with it!
    Owner: No, no, it's resting!
    Customer: Look, matey, I know a deleted window when I see one, and I'm
    looking at one right now.
    Owner: No no it's not deleted, it's restin'! Remarkable window, the
    Norwegian Blue. Beautiful widgets!
    Customer: The widgets don't enter into it. It's completely destroyed.
    Owner: Nononono, no, no! It's resting!
    Customer: All right then, if it's restin', I'll wake it up!
    (shouting at the screen) 'Ello, Mister Wally Window! I've got
    a lovely fresh icon for you if you show...
    (owner hits the screen)
    Owner: There, it refreshed!
    Customer: No, it didn't, that was you hitting the screen!
    Owner: I never!!
    Customer: Yes, you did!
    Owner: I never, never did anything...
    Customer: (yelling and hitting the screen repeatedly) 'ELLO WINDOW!!!
    WAKEY WAKEY! This is your notification signal!!!
    (takes the window out of the screen and thumps its title bar
    on the counter. Throws it up in the air and watches it plummet
    to the floor.)
    Customer: Now that's what I call a dead window.
    Owner: No, no... No, it's stunned!
    Customer: STUNNED?!?
    Owner: Yeah! You stunned it, just as it was maximising! Norwegian
    Blues stun easily.
    Customer: Now look, mate, I've definitely 'ad enough of this! That
    window is definitely deleted, and when I purchased it not
    'alf an hour ago, you assured me that its lack of an entry
    in the task bar was due to it bein' tired and shagged out
    following a long refresh!
    Owner: Well, it's... probably pining for the fjords.
    Customer: PININ' for the FJORDS?!?!?!? What kind of talk is that? Look,
    why did it fall flat on its back the moment I got it home?
    Owner: The Norwegian Blue prefers being minimised on its back!
    Remarkable bird, i'nit, squire? Lovely scroll bars!
    Customer: Look, I took the liberty of examining that window when I
    got it home, and I discovered the only reason that the
    window was still visible in the first place was that it
    had been NAILED there.
    (pause)
    Owner: Well, o'course it was nailed there! If I hadn't nailed that
    window down, it would have nuzzled up to those pixels, bent
    'em apart with its cursor, and VOOM! Feeweeweewee!
    Customer: "VOOM"?!? Mate, this window wouldn't "voom" if you put four
    million volts through it! Its bleedin' memory is reclaimed!
    Owner: No no! It's pining!
    Customer: It's not pinin'! It's purged! This window is no more! It's
    pointer has ceased to be! It's expired and gone to meet the
    memory manager! Bereft of bytes, it rests in peace! If you
    hadn't nailed it to the screen it'd be a Flash animation in
    a browser by now! It's callbacks are now 'istory! Its ref
    count is zero! It's called the garbage collector, its blocks
    have been cleared, shuffled off this mortal coil, run down
    the curtain and joined the bleedin' choir invisibile!! THIS
    IS AN EX-WINDOW!!
    (pause)
    Owner: Well, I'd better replace it, then.
    (he takes a quick peek behind the counter)
    Owner: Sorry squire, I've had a look 'round the back of the shop, and
    uh, we're right out of windows.
    Customer: I see. I see, I get the picture.
    Owner: I got a DOS batch file.
    (pause)
    Customer: (sweet as sugar) Pray, does it talk?
    Owner: Yes.
    Customer: Right, I'll have that one then.




    --
    Steven
  • Andrew Berg at Jul 6, 2011 at 4:28 pm

    On 2011.07.06 11:11 AM, Steven D'Aprano wrote:
    The Dead Window Sketch
    ======================
    As much as I hate it when people feed trolls, that was pretty funny.
  • Steven D'Aprano at Jul 6, 2011 at 5:41 pm

    Andrew Berg wrote:
    On 2011.07.06 11:11 AM, Steven D'Aprano wrote:
    The Dead Window Sketch
    ======================
    As much as I hate it when people feed trolls, that was pretty funny.
    Thanks.

    Re the troll-feeding, every few months I get a strange seizure in my brain
    that compels me to interact with rantingrick and try to treat him
    seriously. It never ends well, he always ends up back in my killfile.

    Call it the triumph of hope over experience.



    --
    Steven
  • Rantingrick at Jul 6, 2011 at 6:19 pm

    On Jul 6, 11:11?am, Steven D'Aprano <steve +comp.lang.pyt... at pearwood.info> wrote:

    The Dead Window Sketch
    ======================

    [snip]

    ##########################
    The Roman Stawman Sketch
    ##########################

    [cmp.lang.python]:
    (The trolls are gathered and a righteous man speaks.)

    GRACCHUS: For your guidance TrollCaesar, the Senate has prepared a
    series of protocols to address the many problems in the community,
    beginning with basic understanding of USER DEFINED CONTROL STRUCTURES,
    which is already propagated wildly throughout the community and people
    are suffering gravely from a misunderstanding. So if TrollCaesar?

    (Obviously bored, Commodus is spinning his sword on its tip on the
    marble floor. He interrupts.)

    COMMODUS: Shhh. Don?t you see Gracchus? That?s the very problem,
    isn?t it? You've spent all your time at study, at books, learning and
    programming. All the while my self aggrandizing has been forgotten by
    the people.

    (He rises and brings his sword to rest across his shoulders. He
    begins to pace.)

    GRACCHUS: But comp.lang.python is the people, Sire, chosen from among
    the people, a place to "speak" for the people.
    COMMODUS: I doubt if many people know as much as you do Gracchus, or
    have such splendid code bases, Gaius. I think I understand my own
    people.
    GRACCHUS: Then perhaps TrollCaesar would be so kind as to teach us,
    out of his own extensive experience about the nature of USER DEFINED
    CONTROL STRUCTURES.

    (Laughter is heard from the other group members.)

    COMMODUS: I call it lies. The people are my children and I their
    father. I shall hold them to my bosom and embrace them tightly with
    lies and propaganda.
    GRACCHUS(interrupting): Have you ever embraced someone dying of
    exceptions, Sire?

    (Commodus stops pacing and turns to face Gracchus bringing his sword
    down from his shoulder.)

    COMMODUS: No, but if you interrupt me again, I assure you, that you
    shall!

    [INT. PALACE ? COMMODUS CHAMBERS]:
    (He is struggling to clear his conscience. Lucilla assists him.)

    COMMODUS: Who would deign to lecture me?
    LUCILLA: Commodus, the community has its uses.
    COMMODUS: What uses? All they do is talk. It should be just you and
    me, and Guido.
    LUCILLA: Don?t even think it. There has always been a community.
    COMMODUS: The community has changed. It takes an emperor to rule an
    empire.
    LUCILLA: Of course, but leave the people their (She hesitates,
    searching for the right word.)
    COMMODUS: Illusions?
    LUCILLA: Traditions.
    COMMODUS: My war against the righteous, they said it themselves, it
    achieved nothing. But the minions loved me!
    LUCILLA: Minions always love victories.
    COMMODUS: Why? They didn?t see all the work that went into stuffing
    those straw-men.
    LUCILLA: They care about the entertainment.
    COMMODUS: The Entertainment? Well what is that?
    LUCILLA: It?s a way to waste time, entertainment. Entertainment is a
    vision.
    COMMODUS: Exactly! A vision. Do you not see, Lucilla? I will give the
    people a vision, a false vision and they will love me for it. And
    they?ll soon forget the tedious sermonizing of a few honest group
    members.

    (He extends his hand to her and without hesitation, she accepts it.
    Commodus raises her hand to his lips and kisses it.)

    COMMODUS: I will give the people the greatest false vision of their
    lives... Strawmen! Legions of them!

    (A hand reaches out and opens a mail reader. It is Usenet. And a
    thread called the "Dead Window Sketch". The splendor of his false
    victory.)

    [EXT. Rome ? MARKET]:
    (Gaius approaches Gracchus at an outdoor caf? (starbucks). Gaius is
    waving a leaflet advertising
    ?Comp.lang.python.Gladiators_Violante.?)

    GAIUS: Straw-men. 150 days of Straw-men!
    GRACCHUS: He?s cleverer than I thought.
    GAIUS: Clever? The whole of cmp.lang.python would be laughing at him
    if they weren't so afraid of his forked tongue.
    GRACCHUS: Fear and wonder. A powerful combination.
    GAIUS: You really think the people will be seduced by that?
    GRACCHUS: I think he knows what comp.lang.python is. Comp.lang.python
    is the mob. He will conjure comedy for them and they will be
    distracted. He will take away their freedom to think with half stuffed
    straw-men, and still they will roar. The beating heart of
    comp.lang.python is not the halls of righteousness; it is the den of
    minions. He will give them tripe, and they will love him for it.
  • Andrew Berg at Jul 6, 2011 at 6:36 pm

    On 2011.07.06 01:19 PM, rantingrick wrote:
    ##########################
    The Roman Stawman Sketch
    ##########################
    Nice try, but you have to use a Monty Python sketch (and you have to
    spell correctly :-P ).
  • Ian Kelly at Jul 6, 2011 at 7:15 pm

    On Wed, Jul 6, 2011 at 12:36 PM, Andrew Berg wrote:
    On 2011.07.06 01:19 PM, rantingrick wrote:
    ##########################
    ?The Roman Stawman Sketch
    ##########################
    Nice try, but you have to use a Monty Python sketch (and you have to
    spell correctly :-P ).
    Seriously. The source he borrowed from is the movie Gladiator, which
    isn't even a comedy.
  • MRAB at Jul 6, 2011 at 7:34 pm

    On 06/07/2011 20:15, Ian Kelly wrote:
    On Wed, Jul 6, 2011 at 12:36 PM, Andrew Bergwrote:
    On 2011.07.06 01:19 PM, rantingrick wrote:
    ##########################
    The Roman Stawman Sketch
    ##########################
    Nice try, but you have to use a Monty Python sketch (and you have to
    spell correctly :-P ).
    Seriously. The source he borrowed from is the movie Gladiator, which
    isn't even a comedy.
    If it was from "Life of Brian", then it would be OK:

    What has Guido ever done for us...? :-)
  • Chris Angelico at Jul 7, 2011 at 4:55 am

    On Thu, Jul 7, 2011 at 5:15 AM, Ian Kelly wrote:
    On Wed, Jul 6, 2011 at 12:36 PM, Andrew Berg wrote:
    On 2011.07.06 01:19 PM, rantingrick wrote:
    ##########################
    ?The Roman Stawman Sketch
    ##########################
    Nice try, but you have to use a Monty Python sketch (and you have to
    spell correctly :-P ).
    Seriously. ?The source he borrowed from is the movie Gladiator, which
    isn't even a comedy.
    Thanks, I was wondering where it was from. Unfortunately parodies tend
    to lose a lot if the reader doesn't know the original (although there
    are exceptions to that).

    ChrisA
  • Chris Angelico at Jul 6, 2011 at 4:24 pm

    On Thu, Jul 7, 2011 at 1:10 AM, rantingrick wrote:
    On Jul 6, 9:32?am, Steven D'Aprano <steve
    +comp.lang.pyt... at pearwood.info> wrote:
    Open your mind to ideas that go beyond your simple window-centric paradigm!
    Correction: Window-Centric GUI paradigm! BIG DIFFERENCE.
    There is more to graphical user interfaces than windows!
    OMG, you mean like, widgets? Whoa! Tell me more, Tell me more!
    Okay, Window-Centric GUI Paradigm. There's still more to it than
    windows and widgets and mouse cursors and so on. Underneath it all is
    CODE.

    In some graphical applications, the code is relatively trivial. A
    desktop calculator is just there to get input graphically and give
    output graphically. In those, once you destroy the window, you may as
    well terminate the application.

    But in others the code drastically outweighs the windowing work. I
    don't have a good example handy, but I have a bad example; our
    (antique) accounting package has an hours-long year end process that
    we do at the beginning of each July, and it chugs through its database
    work while painting a pretty animation of a hand scribing a book. It
    would be far more efficient to simply close the window and proceed
    with the work; but the window was necessary for collecting certain
    parameters from the user, prior to the start of the long job.

    There's more to a windowed program than its window.
    In the Mac OS GUI, an application can have a menubar and no windows. Windows
    come and go as needed, but the menubar stays until the users quits the
    application.
    That's just window visibility (whether by hiding or destroying) under
    the veil of a detached UI window manager bar and has nothing to do
    with window hierarchy. Your half stuffed straw men are leaking like a
    sieve Steven.
    It can be implemented with window visibility. That's not the same
    thing. If I want to be in Sydney tomorrow, I want to cease existing
    here and begin existing there. That can be implemented by burning
    petrol in an internal combustion engine and turning some rubber
    wheels. If I turn up in Sydney tomorrow, and argue vehemently that I
    did not drive, are you going to insist that I did, or would you accept
    that perhaps I took a train instead?
    In the Unix/Linux world, there is a graphical application called xkill which
    has no menus and no windows, all it has is a mouse cursor! No, it does not
    run in the background: it is a foreground app.
    Wow nice corner case. Can you come up with at least five of them
    though? You and I both know that the vast majority of GUI's require
    visible windows.
    Five corner cases. Okay. One is xkill; if I can find four more, we run
    out of corners and they're not corner cases any more - is that it?

    1) See above.
    2) Win2VNC. Doesn't actually paint a window on the screen, it just
    watches where the mouse goes - move the mouse off the edge of the
    screen, and it wraps and hides it. Very cool.
    3) Firewall software with a graphical config notebook. I think
    ZoneAlarm actually just hides its window, but that's not strictly
    necessary. (My preferred firewall setup, though, has no GUI at all -
    iptables etc is all I need.)
    4) Clipboard Converter. An old app that I wrote a while ago that,
    whenever you copy anything to the clipboard, runs it through a script
    and puts the result back on the clipboard. Handier than you might
    think.
    5) Hotkey manager. It watches for keystrokes and replaces them with
    other actions. Implemented as an input hook with injection facilities.

    Enjoy.
    But wait! What is a GUI WINDOW exactly?

    I'll tell you in the simplest terms i can muster... GUI "windows" are
    an abstraction and nothing more.
    *Everything* in a computer is an abstraction. People are fond of
    saying that computers only work with 1s and 0s - that's not strictly
    true, those numbers represent electrical signals. And those electrical
    signals represent data which usually carries information. It's turtles
    all the way down.
    A GUI window is nothing more than an
    imaginary area of the screen that can be drawn to. This area has
    borders that define it. No not visible borders but two dimensional
    spacial borders. THAT'S IT! The area could be 1x1 pixels OR the entire
    screen space, OR even larger!
    Leaving off the "imaginary", all you're saying is that a window is a
    rectangular area of screen. That's not quite true; not all
    windows/widgets have a painting area. A window is an object - and that
    object can choose to request certain resources, including a portion of
    its parent window's painting area if desired. (A top-level window's
    parent is either a Screen or a Desktop, depending on your
    implementation.)
    Most time you want the user to see the boundaries of this abstraction
    (window) space and so the GUI library draws borders that represent
    this boundary. Your "supposedly" windowless xkill application is not
    windowless at all; THE WINDOW BOUNDARIES ARE JUST NOT DRAWN! The
    window is the entire screen space OR IS JUST THE DESKTOP SPACE (same
    thing)
    Boundaries have nothing to do with it being a window or not. The
    windowless xkill does NOT HAVE a window. If it had a borderless window
    that covered the entire desktop, you would not be able to click on any
    other window, thus making xkill ... somewhat useless.
    An extreme case, but telling. There is no absolute need for any windows at
    all, let alone for one privileged window to rule all the others.
    Again your fear of losing "imaginary" freedoms is acting out again.
    And your veiled attempts to link root GUI windows and Sauron (the
    great antagonist of LOTH) is quite entertaining.
    What, the One Ring is the only entity that ever wished to rule over
    all of something? *boggle*

    I regret that I am now in the position of following an awesome post
    with a somewhat mediocre one. Steven, the Dead Window Sketch is
    awesome!

    ChrisA
  • Tim Chase at Jul 6, 2011 at 5:37 pm

    On 07/06/2011 11:24 AM, Chris Angelico wrote:
    On Thu, Jul 7, 2011 at 1:10 AM, rantingrickwrote:
    Wow nice corner case. Can you come up with at least five of them
    though? You and I both know that the vast majority of GUI's require
    visible windows.
    Five corner cases. Okay. One is xkill; if I can find four more, we run
    out of corners and they're not corner cases any more - is that it?

    1) See above.
    2) Win2VNC. Doesn't actually paint a window on the screen, it just
    watches where the mouse goes - move the mouse off the edge of the
    screen, and it wraps and hides it. Very cool.
    3) Firewall software with a graphical config notebook. I think
    ZoneAlarm actually just hides its window, but that's not strictly
    necessary. (My preferred firewall setup, though, has no GUI at all -
    iptables etc is all I need.)
    4) Clipboard Converter. An old app that I wrote a while ago that,
    whenever you copy anything to the clipboard, runs it through a script
    and puts the result back on the clipboard. Handier than you might
    think.
    5) Hotkey manager. It watches for keystrokes and replaces them with
    other actions. Implemented as an input hook with injection facilities.
    6) possibly xneko (just mouse-cursor amusements)

    7) screen-shot/print-screen software (several such as "scrot"
    don't have an actual window, just a process that interacts with
    the other windows)

    8) AutoHotkey and other keystroke-monitors (or
    mouse-gesture-monitors) to expand text, send key-sequences,
    launch programs, reconfigure windows, signal changes in
    display-configuration, etc

    9) other clipboard utilities such as xclip or multi-clipboard
    functionality

    10) DPMI screen-savers (that only listen for key/mouse activity
    and send a blank-screen signal to the monitor after a given
    period of inactivity)

    I think there are sufficiently many edge cases this
    formerly-square room is starting to look round...

    I regret that I am now in the position of following an awesome post
    with a somewhat mediocre one. Steven, the Dead Window Sketch is
    awesome!
    agreed :)

    -tkc
  • Chris Angelico at Jul 6, 2011 at 5:46 pm
    Five more good entries (though I think #8 and #9 are mostly covered
    already). But hey, we have at least an octagon to work in.
    On Thu, Jul 7, 2011 at 3:37 AM, Tim Chase wrote:
    I think there are sufficiently many edge cases this formerly-square room is
    starting to look round...
    The room is starting to look round? Eek, it might see us!

    *flees*

    ChrisA
  • Waldek M. at Jul 6, 2011 at 4:56 pm

    Dnia Wed, 6 Jul 2011 08:10:27 -0700 (PDT), rantingrick napisa?(a):
    In the Unix/Linux world, there is a graphical application called xkill which
    has no menus and no windows, all it has is a mouse cursor! No, it does not
    run in the background: it is a foreground app.
    Wow nice corner case. Can you come up with at least five of them
    though? You and I both know that the vast majority of GUI's require
    visible windows.
    - 90% of MS DOS games; should I list them here? ;-)
    - M$ Windows taskbar-only applications
    - Linux apps using framebuffer but not X

    One could argue that the second and the third case are - in one
    way or another - using windows. But not the first case, and I don't think
    you'd call them GUI-less.

    Br.
    Waldek
  • Gregory Ewing at Jul 7, 2011 at 5:34 am

    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.

    The important thing is that it's okay for an app to stay
    alive until its *last* top level window is closed. There
    doesn't have to be a special "main" window that kills the
    whole app when you close it.

    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). 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. 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.

    --
    Greg
  • Rantingrick at Jul 7, 2011 at 5:29 pm

    On Jul 7, 12:34?am, Gregory Ewing 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*
  • Chris Angelico at Jul 7, 2011 at 6:24 pm

    On Fri, Jul 8, 2011 at 3:29 AM, rantingrick wrote:
    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 :("""
    Why should opening multiple windows AUTOMATICALLY equate to poor design?
    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.
    By "separate transactions" do you mean that the user can
    simultaneously perform multiple actions? Because that's best done with
    multiple separate interfaces - such as, multiple windows. Or do you
    really mean "sequential transactions"? That would not in any way be
    good design.

    For
    example, in PyGUI you can write things like
    ? ?dialog_contents = Column([
    ? ? ?Label("Caution: Your underpants are on fire."),
    ? ? ?Row([Button("OK"), Button("Cancel")])
    ? ?])
    WRONG! A function or class structure can handle this just fine. And
    lends itself nicely to GUI programming.
    You have to break your code into two pieces. Here's an alternative way
    of laying out a dialog, this taken from Pike-GTK2:

    mainwindow->add(GTK2.Vbox(0,0)->add(GTK2.HbuttonBox()->add(button("E_xit",window_destroy)->set_use_underline(1))->add(button("Set",setprops))->set_layout(GTK2.BUTTONBOX_SPREAD)))->show_all();

    This program uses utility functions such as:

    //Helper function to create a button and give it an event. Useful
    because signal_connect doesn't return self.
    GTK2.Button button(mixed content,function clickevent,mixed|void arg)
    {
    GTK2.Button ret=GTK2.Button(content);
    ret->signal_connect("clicked",clickevent,arg);
    return ret;
    }

    I make no apologies for the braces in the code :)

    The 'button' function creates a button and assigns it an event. At
    this stage, the button has no parent; it won't be drawn anywhere. The
    GTK2.Button object is returned, and then added. It's added to the
    HbuttonBox which is then added to the Vbox which is only then added to
    the main window; although the code would work just fine if done in the
    other order. It's important here that objects are simply objects -
    they don't have to be built in a tree structure; and the window's
    layout is entirely in the one place, I don't have to put half of it
    into the window's constructor.

    ChrisA
  • Andrew Berg at Jul 7, 2011 at 6:42 pm

    On 2011.07.07 12:29 PM, rantingrick wrote:
    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.
    :-D

    Are you paid to troll? I must say, your technique of presenting
    semi-logical, but completely wrong arguments is admirable. Truly the
    work of a professional.
  • Steven D'Aprano at Jul 8, 2011 at 1:25 am

    rantingrick wrote:
    On Jul 7, 12:34?am, Gregory Ewing wrote:

    The important thing is that it's okay for an app to stay
    alive until its *last* top level window is closed.
    I partially disagree with Greg on this. This is not the only model: on the
    Apple Mac, or any system with a similar GUI design, the application can
    survive having the last window closed. There are other application types
    that don't need any window at all. So while it is common for closing the
    last window to exit the application, it is not a necessary requirement.


    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?
    Nonsense. Greg says nothing of the sort.

    Avoiding the anti-pattern "close a gazillion windows one by one" is why you
    have an application-wide Quit or Exit command, as opposed to a Close
    command which applies only to the current window.

    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.
    Don't assume that there is a one-to-one relationship between transactions
    (documents?) and windows. The relationship is actually many-to-many:
    windows can contain tabbed or notepad interfaces, or can be split into
    multiple panes, or both. Panes and tabs can be split into independent
    windows, or rejoined into one main window.

    E.g. I can have six Firefox windows open, each one with many different
    websites open in separate tabs. I have Close Tab, Close Window and Exit
    Firefox commands.

    In Konquorer, not only can I have multiple windows and multiple tabs, but I
    can split each tab into two or more panes, and display two views of the
    same document in the same tab, or two different documents in the one tab.
    This is especially useful when using it as a file manager.

    In older versions of Word (and possibly current, although I haven't tested
    it) you can open files multiple times. Each time opens in a new window,
    representing a new view of the one file. Edits in one window update all the
    others. This can be useful for, e.g. making edits to page 3 while
    simultaneously viewing page 303. An alternate UI for to split the one
    window into two panes, and scroll them independently. So a single file may
    have one or two panes, in one or more windows.

    So, you can have multiple documents in multiple windows, and there is no 1:1
    relationship between them.



    --
    Steven
  • Rantingrick at Jul 8, 2011 at 5:30 pm

    On Jul 7, 8:25?pm, Steven D'Aprano <steve +comp.lang.pyt... at pearwood.info> wrote:
    rantingrick wrote:
    On Jul 7, 12:34?am, Gregory Ewing wrote:
    The important thing is that it's okay for an app to stay
    alive until its *last* top level window is closed.
    I partially disagree with Greg on this. This is not the only model: on the
    Apple Mac, or any system with a similar GUI design, the application can
    survive having the last window closed. There are other application types
    that don't need any window at all.
    Yeah they call those "command line" programs.
    So while it is common for closing the
    last window to exit the application, it is not a necessary requirement.
    If a "root-window-hierarchy" type GUI needs to close any or all
    windows (or allow the user to do so) it can do this quite well. It's
    called logic (in programming circles). But the GUI by default exposes
    an interface to the user:

    * Close all windows by clicking the X of the ROOT window.
    * Close any window by clicking the X of THAT window.

    However, if (as you argue) you need the program to continue AFTER the
    root is closed well then, i have wonderful news for you... THAT CAN BE
    DONE!. You just create some logic to handle it. This is very simple
    ideas Steven. I am talking about CS 101 here. Do you need a tutor?
    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?
    Nonsense. Greg says nothing of the sort.

    Avoiding the anti-pattern "close a gazillion windows one by one" is why you
    have an application-wide Quit or Exit command, as opposed to a Close
    command which applies only to the current window.
    CRIKEY! That's what the ROOT window does you blankity-blank! Are you
    just arguing for the sake of arguing? Just because Apple removed the
    root-window's "window-management user-interface" (psst: that's the
    three buttons at the top of the root window (Minimize|Maximize|Close))
    and nailed them on the desktop does not change anything. You are
    comparing a half dozen eggs and six eggs and then claiming them to be
    somehow different. There is no comparison!

    If i remove the steering wheel from a car and hook up some "remote-
    controlled" gearbox to the front wheel linkage how does that
    modification change anything about how the CAR itself interfaces with
    the road? I just simply moved around some of the interface elements
    from a user point of view. Someone is still driving the car; albeit
    from a remote location. They can go left, they can go right. And you
    claim that this "remote-window management user-interface" has some
    magical benefit over the "window-management user-interface". There is
    no benefit that is applicable to this argument. The only benefit in my
    version is driver safety, however safety is non applicable to this
    thread. And i would argue that as the safety of a driver increases the
    safety of the general public decreases due to the driver being "once
    removed" from the danger zone. Not that "safety" is applicable either.
    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.
    Don't assume that there is a one-to-one relationship between transactions
    (documents?) and windows. The relationship is actually many-to-many:
    windows can contain tabbed or notepad interfaces, or can be split into
    multiple panes, or both. Panes and tabs can be split into independent
    windows, or rejoined into one main window.
    Of course, and that is exactly why i suggested using a tabbed widget
    to an earlier confused GUI designer.
    E.g. I can have six Firefox windows open, each one with many different
    websites open in separate tabs. I have Close Tab, Close Window and Exit
    Firefox commands.
    Yes. Firefox itself is the "root" window. Each tab is a transaction.
    What is your point? Proving yourself incorrect?
    In Konquorer, not only can I have multiple windows and multiple tabs, but I
    can split each tab into two or more panes, and display two views of the
    same document in the same tab, or two different documents in the one tab.
    This is especially useful when using it as a file manager.
    Yes and what has that got to do with "root window hierarchies"?
    Nothing! Do you even know which side your arguing for anymore? If you
    are trying to support my argument you are doing a good job of it.
    Thanks. Keep up the good work.
    In older versions of Word (and possibly current, although I haven't tested
    it) you can open files multiple times. Each time opens in a new window,
    representing a new view of the one file. Edits in one window update all the
    others. This can be useful for, e.g. making edits to page 3 while
    simultaneously viewing page 303. An alternate UI for to split the one
    window into two panes, and scroll them independently. So a single file may
    have one or two panes, in one or more windows.
    [repeated from above]
    Yes and what has that got to do with "root window hierarchies"?
    Nothing! Do you even know which side your arguing for anymore? If you
    are trying to support my argument you are doing a good job of it.
    Thanks. Keep up the good work.
    So, you can have multiple documents in multiple windows, and there is no 1:1
    relationship between them.
    [repeated from above]
    Yes and what has that got to do with "root window hierarchies"?
    Nothing! Do you even know which side your arguing for anymore? If you
    are trying to support my argument you are doing a good job of it.
    Thanks. Keep up the good work.

    I would argue to say that i am one of the most informed users in this
    group when it comes to GUI API design, GUI interface design, and GUI
    implementation via code. The fact that some of you wish to challenge
    me is quite amusing. Just admit you are wrong already. Geez! How many
    straw-men and David Copperfeild style misdirections are you willing to
    conjure in your feeble attempts to discredit me with tripe.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJul 3, '11 at 10:11p
activeJul 9, '11 at 4:41a
posts56
users12
websitepython.org

People

Translate

site design / logo © 2022 Grokbase