up with PyGUI!

[OKB (not okblacke)]

Ed Leafe wrote:

> I am interested in any alternatives that would benefit our users;
> my curiosity is about the payoff for adopting an alternative
> approach such as yours. If such a payoff isn't there, I can't spend
> a lot of time pursuing it. That's why I'm constantly asking you to
> explain the benefit, not just the theory, behind this idea.

    	Well, admittedly I've only begun doing this, but my idea is that 
the benefit is in readability.  Suppose your code is structured like 
this:

class frame(wxFrame):
    	def __init__(self, parent):
   	    	button1 = wxButton(parent=self, ...)
    	    	button2 = wxButton(parent=self...)
    	    	panel = wxPanel(parent=self...)
    	    	listBox1 = wxComboBox(parent=panel...)
    	    	listBox2 = wxComboBox(parent=panel...)
    	    	button3 = wxButton(parent=panel...)
    	    	text = wxTextCtrl(parent=panel...)
    	    	sizer1 = wxBoxSizer(...)
    	    	sizer1.Add(listBox1)
    	    	sizer1.Add(listBox2)
    	    	sizer1.Add(button3)
    	    	sizer1.Add(text)
    	    	panel.SetSizer(sizer1)
    	    	sizer2 = wxBoxSizer(...)
    	    	sizer2.Add(button1)
    	    	sizer2.Add(button2)
    	    	sizer2.Add(panel)
    	    	self.SetSizer(sizer2)
    	    	# etc.
###

    		How am I supposed to know, just by looking at that, which 
controls are in which sizers and what the relationship is between the 
two sizers?  I have to visually parse every single line -- not just the 
creation of each widget, but also the line that adds it to a sizer.  And 
there could easily be an inconsistency -- you might accidentally give a 
widget a parent that's inconsistent with the sizer you add it to.  With 
a nested structure it becomes clear:

class frame(wxFrame):
    	class sizer1(wxBoxSizer):
    	    	class button1(wxButton):
    	    	    	# name, size, etc.
    	    	class button2(wxButton):
    	    	    	# etc.
    	    	class panel(wxPanel):
    	    	    	class sizer2(wxBoxSizer):
    	    	    	    	class listBox1(wxComboBox): # etc.
    	    	    	    	class listBox2(wxComboBox): # etc.
    	    	    	    	class button3(wxButton): # etc.
    	    	    	    	class text(wxTextCtrl): # etc.

    	Now, I can see your point: this does amount to essentially an abuse 
of the "class" keyword.  But to me this is a small price to pay for the 
increase in readability and the reduction in redundancy.  Why should I 
have to separately specify that: a) a certain widget is being created; 
b) it has a certain parent; c) it goes in a certain sizer; c) that sizer 
goes in the parent widget?  I regard these all as essentially 
restatements of a single overall fact about the widget's position in the 
interface.

    	So, yes, this is a very unusual use for the word "class".  But the 
point here is not the keywords being used.  The idea is to have the 
structure of the GUI reflected clearly in the layout of the code.  If 
Python's syntax were more flexible, this could perhaps be done in other 
ways -- I'm not saying I want that -- but as it is the only real way to 
construct nested structures in Python is with class definitions. 

-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown