up with PyGUI!

Nicolas Fleury nid_oizo at yahoo.com_removethe_
Thu Sep 23 23:28:24 EDT 2004


Hans Nowak wrote:
> Admittedly, having to state the parent-child (or container-child) 
> relationship twice is redundant.  I am still thinking of ways to make 
> that work better. Maybe I'll post some suggestions on my weblog, so 
> people can discuss it there, rather than on the newsgroup.

My suggestion is to do as in Python for normal objects; they exists 
because they are referenced.  The widget can even be added under 
multiple parents; under the hood multiple wx widgets are created.

>> It is also more usable, since you can do things like:
>> myFrame.SetMenuBar(MenuBar([
>>     Menu("File", [
>>         Item("&New\tCtrl+N", self.onNew),
>>         Menu("Some sub menu...", ...)]
>>     Menu("Edit", ...)]
> 
> 
> In fact, a nested list would suffice here to contain the structure of 
> the whole menu.  I have an application that uses just that.  Maybe 
> something that can be added as well.

Admittedly I did the same thing.  But I changed it to something like my 
example.  Instead of having one piece of code analyzing nested lists or 
tuples, everything is delegated to small classes and therefore 
expandable by user and more flexible.

It's easier to do that with menus because they are not wx.Window IIRC 
and you don't have to pass the parent in constructors.  What would be 
really cool is to have the same approach for everything:

panel = Panel(
     BoxLayout(VERTICAL, [
         Label("Some text),
         BoxLayout(HORIZONTAL, [
             Button("OK", self.onOk),
             Button("Cancel", self.onCancel)])]))

What is cool about that approach is that you can do everything with 
constructors, but can still do more complex things in mulitple 
statements like in wxPython (you can still have add methods).  It has 
also the advantage to have the capability to present things 
hierarchically, as with other suggestions of using metaclasses.

>> The problem is that that explicit cross-referencing between parent and 
>> child forces the parent to be created before, removing capabilities 
>> like that one.
> 
> But adding capabilities as well... see my example in a previous post.

The problem with:
b = Button(parent, ..., layout={'expand': 'both', 'border': 2})
is that the constructor of Button is receiving arguments to a layout it 
should not know about.  The arguments can also be specific/complex for a 
certain type of layout.  It mean that widgets contructors, in addition 
to parent argument, would also need flags for the layout.  I see it the 
other way, ownership should be specified when doing the composition 
itself, and widgets constructors should only take flags for themselves 
and their children if they can have one.

Note that I'm describing what kind of API I would like to use, not 
necessarily the one you want to make;)

Cheers,
Nicolas



More information about the Python-list mailing list