Originally, the Background class was named after the idea of a 
HyperCard background, which is a container shared by one or more cards 
containing common layout objects and code shared by all cards on the 
background. Since PythonCard doesn't currently follow the HyperCard 
stack, background, and card metaphor and won't as far as release 1.0 is 
concerned, there has been debate on and off about changing the name of 
the class to something more common like Window or Form.

Technically, the Background class is a top-level wx.Frame which 
contains a wx.Panel and may also have a menu bar, tool bar, and status 
bar. The PageBackground class added in release 0.8.1 is a wx.Panel, 
which contains another wx.Panel; the extra panel might be dropped, it 
is there now to guarantee that both Background and PageBackground 
semantics are the same as far as user-code is concerned.

Because of the standardized use of a child Panel in the Background, it 
would probably be confusing to refer to the Background as a Frame. 
Window might be okay, but the term is fairly generic and could be 
confused with the wx.Window base class. Form might be okay, except that 
it seems like a better fit for what Panel is in wxPython (i.e. no menu 
bar or status bar).

Anyway, the main reason I'm tempted to just leave the name alone for 
PythonCard 1.0 is that every single sample, tool, resource file, docs, 
and much of the framework refer to Background and we've been using that 
terminology for the last three years on the mailing list. Since I 
expect there to be very few changes to the core framework and API 
before PythonCard 1.0 is released, changing such a fundamental name 
seems like a bad idea since it impacts hundreds of files. OTOH, if we 
decide to make any changes to the resource file, like using an 
underscore instead of a dot (e.g. minimal_rsrc.py), making the resource 
directly importable, etc. then if there is going to be a name change, 
it would be nice to take care of both issues at once for a 0.9 release.

As always, I would like to get some feedback, either pro or con, before 
putting this issue to bed. Remember, that the key issue with doing a 
PythonCard 1.0 release is that the framework API will be frozen, so 
that any subsequent 1.x releases will only be able to add classes, 
methods, named method args with default values, or other features that 
won't break code written for 1.0. It is very important to resolve 
fundamental problems with PythonCard in the next month or so to make 
PythonCard 1.0 as solid as possible and usable for a long time.

Any fundamental changes to PythonCard that would break older 1.x code 
will be pushed to the PythonCard 2.0 development branch. I expect that 
the current notion of containers, the Background name, etc. will be 
reworked when we get to that point.

ka



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Pythoncard-users mailing list
Pythoncard-users@[...].net
https://lists.sourceforge.net/lists/listinfo/pythoncard-users