[Pythoncard-users] generic container model

[Donnal W. <don...@ya...>]

Kevin Altis" <al...@se...>
> There is no built-in support for the wx.Notebook class
> right now, which is what you would use to do a real tabbed
> interface. This is mostly due to PythonCard having a "flat"
> layout model rather than supporting a generic container
> model ...

<delurking>
Aha! A critical insight. If I understand correctly this "flat"
model also explains (at least in part) why sizers are problematic
to implement in the framework. Ideally, each container should have
a built-in sizer to which components are automatically added as
they are added to the container. The kind of sizer should be
determined by the container, and the parameters for each component
should be passed like 'size' and 'pos' are now. (Another useful
parameter for each component would be a data model from some kind
of abstraction layer.)

> ... where you could have a different layout in each notebook
> tab/page. This has been discussed a number of times on the
> mailing list and is obviously a big missing feature, but I
> don't really know how to support it correctly. There was one
> attempt to incorporate this into the framework and
> resourceEditor, but it was never incorporated into the main
> cvs code or updated for release 0.8.
>
> It is probably time for a separate discussion thread on the
> issues and possible solutions such as treating each page as
> a type of child window where only the components of the child
> window resource are used. I'm just brainstorming here. ...

Brainstorming further, I would suggest that for PythonCard *2.0* a
class-based rather than an instance-based framework be considered.
Each container would be defined as a *class* (with an appropriate
resource-file notation, something other than a dictionary), such
that multiple instances could be created if so desired. In either
case, however, as the class is instantiated (initialized) the
parent-child relationships are established as well as sizer
relationships.

> ... You would end up with a separate source and resource file
> for each tab/page. I guess the references to each tab layout
> would end up being something like  
> self.components.notebook[0].components.field1, etc. where
> each page (window) of the notebook is referenced via a list.

In a class-based framework, the top-level resource file would
import component resource files as they are needed. Just a thought.
</delurking>

Regards,
Donnal Walter
Arkansas Children's Hospital