up with PyGUI!

[Bengt Richter]

On 26 Sep 2004 02:31:33 GMT, "OKB (not okblacke)" <brenNOSPAMbarn at NObrenSPAMbarn.net> wrote:

>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.
>
I could see a way to write this in terms of instances. Also playing a trick so that keyword
arg CC=True would return a custom class instead of an instance, for repeated use of a
particular customization:

CustButtton = Button(CC=True, bgcolor='lightgreen', namefmt='cbtn%s', nextnameno=100)
CustistBox = ListBox(CC=True, kind=ListBox.DROPDOWN, width=40, maxdrop=10) # default namefmt is cls.__name__+'%s'

myFrame = (
  Frame(
    Sizer(
      CustButton(size= ... etc),
      CustButton(size= ... etc),
      Panel(
        Sizer(
          CustListBox(etc),
          CustListBox(etc),
          CustButton(etc),
          Text( etc )
        )
      )
    )
  )
)

IOW, an *args tuple of child instances is passed to each constructor, and the whole thing
would make a tree of instances. To make customized instances from the same custom class,
I thought to make the base classes return custome classes with class variables preset per
keyword args in the case where there is a CC=True keyword arg. Some thought is required to
make this support whole custom subtrees...
...
# attribute access could be hacked to allow access to the tree in terms of attribute
paths naming supplied or auto-generated names, e.g.,

myFrame.frame1.sizer1.cbtn101.text='Hi'  # (default names except CustButtons)

>    	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. 
You don't mean that ("...only real way...") as broadly as it sounds, do you?

Regards,
Bengt Richter