Implicit initialization is EVIL!

[Waldek M.]

Dnia Wed, 6 Jul 2011 08:10:27 -0700 (PDT), rantingrick napisa³(a):

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

 

[Tim Chase]

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

 

[Steven D'Aprano]

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.

 

[Chris Angelico]

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.

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

 

[rantingrick]

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]

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

Nice try, but you have to use a Monty Python sketch (and you have to
spell correctly ).

 

[Ian Kelly]

Nice try, but you have to use a Monty Python sketch (and you have to
spell correctly ).

Seriously. The source he borrowed from is the movie Gladiator, which
isn't even a comedy.

 

[MRAB]

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]

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

 

[Gregory Ewing]

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.

 

[rantingrick]

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]

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]

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]

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.

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.

 

[Gregory Ewing]

So you prefer to close a gazillion windows one by one?

If I want to close all the windows, I can use the application's
"Quit" or "Exit" command, or whatever the platform calls it.

(Note that if there is a separate instance of the application
for each window -- as was suggested earlier -- then you don't
have that option, and you have to close them one by one
anyway.)

WRONG! A function or class structure can handle this just fine.

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

Which is *exactly* what I said you would have to do in
Tkinter! Each widget creation requires a separate statement,
with the parent passed in at each step. This is nowhere
near as convenient as the nested function call style.

 

[rantingrick]

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?

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.

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

 

[Steven D'Aprano]

Yeah they call those "command line" programs.

Only idiots who don't understand that Graphical User Interface does not
equal Window.

I'm done with this conversation. Welcome to Killfile City, population
rantingrick.

See you in a few months. Try to have grown up by then.