Implicit initialization is EVIL!

[rantingrick]

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 <greg.ew... at canterbury.ac.nz> 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.