pythoncard-users

[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

Re: [Pythoncard-users] generic container model

[Alex T. <al...@tw...>]

At 13:47 13/09/2004 -0700, Donnal Walter wrote:
><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.

If PythonCard had a non-flat model, then it would be easier to change it to 
have explicit containers (each being a sizer of one kind or another).

But I think there's a more fundamental problem: it would require a 
different approach to laying out your GUI.  Using sizers kind of requires 
that you have a plan for the layout of controls, and can then describe a 
hierarchy of sizers and place controls within them. This is, I think, 
rather contrary to the freedom that PythonCard gives you to rapidly 
prototype and play with different controls and arrangements of them.

There's certainly a contradiction between the idea that you "place" 
controls (as in Pythoncard) versus "arrange the order and relative 
position" of controls, and let sizers shuffle them into their final (but 
dynamic) positions.

I've been playing around with sizers in Pythoncard; I've built a couple of 
"auto-sizer" functions that take a component layout as found in a resource 
file, and generate a reasonable first-cut at arranging those into sizers.

Basic idea is that it should take the component positions (and use some 
default assumptions about different components) to build a default set of 
sizers. This can be aided by some "hints" added to the component data 
(currently using "custom data" in the components, but if the idea ever gets 
anywhere, it might be possible to add something to the resource editor to 
support this more directly) to guide its actions.  The auto-sizer can then 
either just operate, or it can spit out the source code that will make 
equivalent simple sizer calls, and can therefore be the starting point for 
custom programming.

I was feeling quite optimistic about it a couple of weeks ago - and then 
got side-tracked. I'll work on it a bit more, and if I can come up with 
something that works well enough, and is easy to explain, I'll make it 
available to anyone who wants to play around with sizers.

-- Alex.

[Pythoncard-users] Re: generic container model

[Kevin A. <al...@se...>]

Sigh, I just can't seem to make a short post...

On Sep 13, 2004, at 1:47 PM, Donnal Walter wrote:

> 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.)

No, sizers are an orthogonal issue. You can stick sizers into a layout 
once the components are created or you can create and embed the 
controls as each sizer is created. Regardless, the default tab order 
and overlap of the controls is dependent on the order the controls are 
created and has nothing to do with the sizers. This may not be apparent 
when editing XRC files, using wxDesigner, wxGlade, etc. but that is how 
it works. Sizers do not inherit from wx.Window, they are a way of 
controlling layouts.

As many of the PythonCard samples and tools show it is very simple to 
use "raw" wxPython sizer code in a PythonCard program, it looks and 
behaves exactly like it would in a plain wxPython program. What 
PythonCard doesn't support is specifying sizers in the resource file 
nor does it provide any UI tools in the resourceEditor for controlling 
the layout with sizers. It would be relatively easy to support sizer 
descriptions in the resource file, it would just be another nested list 
attribute that would make references to the components list.

However, the bigger problem is doing the layout tool that uses sizers, 
but remains as easy to use as a direct manipulation paradigm, which is 
what the resourceEditor does now. I don't know how to make a layout 
tool based on sizers that is easy to grasp, certainly XRCed, 
wxDesigner, and wxGlade, while very nice tools don't seem simple to 
make and modify layouts, at least to me. wxGlade is probably the best, 
but it seems quite daunting, especially to newbies. Other opinions?

The "flat" model I was referring to has more to do with all the bits of 
wxPython that are being hidden in order to make PythonCard programs 
simple. For example, the Background which is what all programs use is a 
wx.Frame that contains a wx.Panel with an optional menu bar and status 
bar. There is only one set of components (wxPython controls) on the 
panel which is always accessed via the self.components list from the 
Background.

The advantage of this is that there is a whole lot of wxPython code 
that you don't have to put in your program, and probably more 
importantly over time, all PythonCard program source code looks the 
same. This is the same sort of reasoning which led to standardizing the 
event names and auto-binding events so programs wouldn't have a whole 
lot of event binding cruft in the initialization as well as completely 
different names for all the events which just makes reading other 
peoples code that much more difficult. It is also why the layout is 
kept separate from the program logic/source.

You don't have to figure out the object hierarchy doing a whole bunch 
of GetChildren() or GetParent() iterations. The background always has 
the same interface and behaves the same way, so Backgrounds can be 
reused as child windows or now, with the addition of the PageBackground 
class as pages in a Notebook. My hope is that this really is simpler 
for people to grasp and we aren't just being different to be different.

There is also the issue of not having the concept of a compound 
component which could be made up of one or more other components. 
Rowland has done some work in that area, but it still hasn't made it 
into the main cvs branch because we needed to make some fundamental 
changes to how resources and components are loaded as well as how 
events are handled. Now that I've created the PageBackground class I 
can see where we might actually be able to use a variation on that 
which would act as a nice building block.

>> ... 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>
>
I don't know what PythonCard 2.0 will look like, we'll have to wait 
until 1.0 is done and see just how far users take it in 1.x releases 
without tampering with the API... I'm pretty sure people will surprise 
us with what they are able to do, even with a framework and tools that 
are more limited than just using wxPython. What I do know is that if I 
still end up being the primary driving force for how PythonCard works 
then my tendency will be to keep it simple. There are many other tools 
for using wxPython, so it seems like a bad move to make PythonCard 
complicated and lose whatever small audience it may already address.

Certainly, some parts of PythonCard can be extracted from the framework 
such that they could be used in any wxPython program, but it isn't 
clear that the general wxPython-user base really wants that.

I still think a lot of your ideas for data driven applications are good 
but probably more appropriate for frameworks people might come up with 
on the wxPython-users or monty mailing list. However, I still like to 
get this kind of feedback because after three years of working on 
PythonCard it is very easy for me to have a very restricted view and 
completely miss the right answer. For example, it has been great 
exchanging ideas and code with Alex because he still has a fresh 
viewpoint and isn't bogged down with the idea baggage I'm carrying 
around. He already came up with two or three improvements to Notebook 
that I hadn't thought of, but after seeing them, they seemed obvious, 
which is what the right answer looks like ;-).

So, the more feedback pro or con the better!

Does any of this make any sense?

ka