Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #8739 > unrolled thread

Implicit initialization is EVIL!

Back to article view | Back to comp.lang.python

Contents

  Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-03 15:11 -0700
    Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-04 08:21 +1000
      Re: Implicit initialization is EVIL! Roy Smith <roy@panix.com> - 2011-07-03 18:32 -0400
    Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-04 20:33 +1200
      Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-04 18:44 +1000
        Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 08:29 -0700
      Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 08:19 -0700
        Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-05 01:40 +1000
          Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 08:46 -0700
            Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-05 02:01 +1000
              Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 10:09 -0700
                Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-05 03:41 +1000
                  Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 12:30 -0700
                    Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-05 07:43 +1000
        Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-04 08:45 -0700
        Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-05 23:11 +1200
        Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-05 23:14 +1200
          Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-06 00:25 +1000
            Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-06 01:17 +1000
              Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 15:38 -0700
            Re: Implicit initialization is EVIL! Web Dreamer <webdreamer@nospam.fr> - 2011-07-05 18:00 +0200
              Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 15:42 -0700
                Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-06 09:20 +1000
                  Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 16:47 -0700
                    Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-06 09:54 +1000
                      Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 17:15 -0700
                        Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-06 10:34 +1000
                          Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 18:10 -0700
                Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-06 18:12 +1200
                  Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-06 06:51 -0700
                    Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-07 00:32 +1000
                      Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-06 08:10 -0700
                        Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-07 02:11 +1000
                          Re: Implicit initialization is EVIL! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-06 11:28 -0500
                            Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-07 03:41 +1000
                          Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-06 11:19 -0700
                            Re: Implicit initialization is EVIL! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-06 13:36 -0500
                            Re: Implicit initialization is EVIL! Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-06 13:15 -0600
                            Re: Implicit initialization is EVIL! MRAB <python@mrabarnett.plus.com> - 2011-07-06 20:34 +0100
                            Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-07 14:55 +1000
                        Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-07 02:24 +1000
                        Re: Implicit initialization is EVIL! "Waldek M." <wm@localhost.localdomain> - 2011-07-06 18:56 +0200
                        Re: Implicit initialization is EVIL! Tim Chase <python.list@tim.thechases.com> - 2011-07-06 12:37 -0500
                        Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-07 03:46 +1000
                    Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-07 17:34 +1200
                      Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-07 10:29 -0700
                        Re: Implicit initialization is EVIL! Chris Angelico <rosuav@gmail.com> - 2011-07-08 04:24 +1000
                        Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-08 11:25 +1000
                          Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-08 10:30 -0700
                            Re: Implicit initialization is EVIL! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-09 14:41 +1000
                        Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-08 13:58 +1200
                        Re: Implicit initialization is EVIL! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-07 13:42 -0500
          Re: Implicit initialization is EVIL! rantingrick <rantingrick@gmail.com> - 2011-07-05 15:47 -0700
            Re: Implicit initialization is EVIL! Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-06 18:29 +1200
    Re: Implicit initialization is EVIL! Robin Becker <robin@reportlab.com> - 2011-07-04 16:35 +0100
      Re: Implicit initialization is EVIL! nn <pruebauno@latinmail.com> - 2011-07-05 08:33 -0700
        Re: Implicit initialization is EVIL! Robin Becker <robin@reportlab.com> - 2011-07-05 17:23 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#8950

On Thu, Jul 7, 2011 at 1:10 AM, rantingrick <rantingrick@gmail.com> wrote:
> On Jul 6, 9:32 am, Steven D'Aprano <steve
> +comp.lang.pyt...@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

[toc] | [prev] | [next] | [standalone]

#8958

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

[toc] | [prev] | [next] | [standalone]

#8962

On 07/06/2011 11:24 AM, Chris Angelico wrote:
> On Thu, Jul 7, 2011 at 1:10 AM, rantingrick<rantingrick@gmail.com>  wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#8965

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 <python.list@tim.thechases.com> 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

[toc] | [prev] | [next] | [standalone]

#9008

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

[toc] | [prev] | [next] | [standalone]

#9044

On Jul 7, 12:34 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> 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*

[toc] | [prev] | [next] | [standalone]

#9047

On Fri, Jul 8, 2011 at 3:29 AM, rantingrick <rantingrick@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#9062

rantingrick wrote:

> On Jul 7, 12:34 am, Gregory Ewing <greg.ew...@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. 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

[toc] | [prev] | [next] | [standalone]

#9089

On Jul 7, 8:25 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> rantingrick wrote:
> > On Jul 7, 12:34 am, Gregory Ewing <greg.ew...@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.

[toc] | [prev] | [next] | [standalone]

#9105

rantingrick wrote:

> On Jul 7, 8:25 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>> rantingrick wrote:
>> > On Jul 7, 12:34 am, Gregory Ewing <greg.ew...@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.

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.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#9064

rantingrick wrote:

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

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

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#9073

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.

[toc] | [prev] | [next] | [standalone]

#8871

On Jul 5, 6:14 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> 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.

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.

[toc] | [prev] | [next] | [standalone]

#8905

rantingrick wrote:

> And how do you EXPLICITY quit the application?

Using its "Quit" menu command.

But that's Mac-specific, and not central to the discussion.
On Linux and Windows, an application will usually exit when
its last window is closed. Either way, there is no need for
a privileged main window.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#8814

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
> x=42
........
did you forget to specify the memory bank and computer (and presumably planet 
etc etc....)
-molly-coddled-ly yrs-
Robin Becker

[toc] | [prev] | [next] | [standalone]

#8840

On Jul 4, 11:35 am, Robin Becker <ro...@reportlab.com> 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
> > x=42
>
> ........
> 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 ... :-)

[toc] | [prev] | [next] | [standalone]

#8844

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web