[Python] Implicit initialization is EVIL!

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

On 03/07/2011 23:21, Chris Angelico wrote:
.........
........
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 ... :-)

On 05/07/2011 16:33, nn wrote:
......
so long since I manipulated the switches of that old pdp-8
-anciently yrs-
Robin Becker

In article <mailman.588.1309731711.1164.python-list at python.org>,
Chris Angelico wrote:
0x14205359 is more likely to give a bus error (odd address) than a
segfault :-)

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

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.
(222, 226)
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.
'Toplevel widget of Tk which represents mostly the main window\n of
an appliation. It has an associated Tcl interpreter.'
(<class Tkinter.Tk at 0x02742210>, <class Tkinter.Misc at 0x02742570>,
<class Tkinter.Wm at 0x0272F780>)
(<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

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

oops. should have used symmetric_difference!
set(['_w', '_setup', 'report_callback_exception', '_do',
'__getattr__', 'loadtk', '_loadtk', 'readprofile'])

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

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.

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

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.
psst: it's called a notebook in GUI jargon. Again, study up on chrome
internals.

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

There's no need for *toplevel* windows to be children
of anything, though.
No, they're not -- the root window is special, because
if you kill it, the whole application exits. Often that
is inconvenient.

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

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

Chris are you playing devils advocate (for my team). I am confused? :-)

Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
Let's use the correct lingo people!

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

And so could i using Tkinter and it's "supposedly" flawed window
hierarchy. Remind me again why we are discussing this?

To do what for me? Close windows? Reclaim memory? Terminate
applications? I don't understand your bogglement.

ChrisA

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?

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

Ah ha. I think we are getting somewhere now. Everything up to this
point has been mostly exposition :-)

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?

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.

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

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.

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.

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

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

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

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

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

agreed :)

-tkc

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.
The room is starting to look round? Eek, it might see us!

*flees*

ChrisA

- 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

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.

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...
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.
Thats was MY complaint yes. On the grounds that widgets require
windows NOT windows require widgets. This fact will confuse folks.
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*

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.

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

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

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.


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.

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.

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?
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.
Of course, and that is exactly why i suggested using a tabbed widget
to an earlier confused GUI designer.
Yes. Firefox itself is the "root" window. Each tab is a transaction.
What is your point? Proving yourself incorrect?
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.
[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.
[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.