Re: [Pythoncard-users] bye bye _delegate, hello direct subclasses

>
> wxPython uses British English spellings for most if not all of its classes
> and methods (colour instead of color). PythonCard has been using American
> English.

You may want to expose both variants as people already using wxPython will
be used to the 6 letter spelling.

>
> We need to be careful to avoid name conflicts with internal wxPython
> attributes and methods such as this, thisone, etc.

You probably mean thisown, right?


>
> Most of the PythonCard component methods simply call their counterparts in
> wxPython and we can probably safely get rid of these duplicated methods.
For
> example:
>
>     def setInsertionPointEnd(self):
>         self.SetInsertionPointEnd()

An easier way to take care of 1-1 mappings like this is to do this at class
scope:

    setInsertionPointEnd = wxTextCtrl.SetInsertionPointEnd

That way you get the new name without the overhead of another function call,
and if you ever need to do something extra in a future release then the
assignment can just be replaced with the def.  You can also use this
technique to allow both spellings of colour mentioned above:

    setForegroundColour = setForegroundColor = \
           wxWindow.SetForegroundColour

>
> Should we continue to have separate PythonCard components such as
TextField,
> PassworldField, TextArea or expose all of the possible styles for
wxTextCtrl
> and just have a single text field control? I lean towards the former
because
> it reduces the initial complexity of use and allows us to follow usage
> conventions such as always using wxTE_RICH for multi-line text fields to
> make GTK and Windows behave the same.

I think it depends on the perceptions of the newbie user.  Do they perceve
the three kinds of components as three different kinds of entry fields, or
three of the same kind with different options selected?


>
> As we transition, should we keep the old methods around for a release or
two
> or just make a clean break?

If you transition away from the PythonCard *Prototype* to the PythonCard
*Framework* (or whatever) at the same time then I would make a clean break.
It will probably be simpler in the long run that way.

--
Robin Dunn
Software Craftsman
ro...@Al...       Java give you jitters?
http://wxPython.org      Relax with wxPython!