Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Implicit initialization is EVIL!

Reply
Thread Tools

Implicit initialization is EVIL!

 
 
rantingrick
Guest
Posts: n/a
 
      07-07-2011
On Jul 7, 12:34*am, Gregory Ewing <(E-Mail Removed)> 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*
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      07-07-2011
On Fri, Jul 8, 2011 at 3:29 AM, rantingrick <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Andrew Berg
Guest
Posts: n/a
 
      07-07-2011
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.



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.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-08-2011
rantingrick wrote:

> On Jul 7, 12:34*am, Gregory Ewing <(E-Mail Removed)> 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

 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      07-08-2011
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
 
Reply With Quote
 
rantingrick
Guest
Posts: n/a
 
      07-08-2011
On Jul 7, 8:25*pm, Steven D'Aprano <steve
(E-Mail Removed)> wrote:
> rantingrick wrote:
> > On Jul 7, 12:34*am, Gregory Ewing <(E-Mail Removed)> 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, 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.


 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-09-2011
rantingrick wrote:

> On Jul 7, 8:25*pm, Steven D'Aprano <steve
> (E-Mail Removed)> wrote:
>> rantingrick wrote:
>> > On Jul 7, 12:34*am, Gregory Ewing <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Implicit initialization is EXCELLENT Steven D'Aprano Python 18 07-07-2011 03:58 PM
array initialization in initialization list. toton C++ 5 09-28-2006 05:13 PM
Initialization of non-integral type in initialization list anongroupaccount@googlemail.com C++ 6 12-11-2005 09:51 PM
Initialization via ctor vs. initialization via assignment Matthias Kaeppler C++ 2 07-18-2005 04:25 PM
Default Initialization Vs. Value Initialization JKop C++ 10 09-22-2004 07:26 PM



Advertisments