Phoenix TODO List

This is just a place for me to jot down things as I think of them. The items are in no particular order, and the fact that something is on this list does not mean that it will ever actually be done. Additionally, no meaning should be attached to items being removed from this file, it could mean that items have been done or just that I’ve decided that they will not be done or no longer apply.

Checklist for all new etg files

• Use a filename that matches the wxWidgets/interface/wx file name that the classes and other stuff is being loaded from. This means that there will be lots of very small files in etg, but it will help to find the interface header source to compare what is being declared there with what is being generated, and to better understand what may need tweaked in the etg script file.
• Read the coresponding interface file and ensure that all classes declared in it are listed in the ITEMS list in the etg file, unless the class should not be wrapped for some reason. Other items from the interface file will be included automatically.
• Do not list classes from other interface files in the etg file.
• Check for any extras added to each class in Classic wxPython and evaluate whether the same extras should be added to the Phoenix verison. For example, there may be additional C methods added on to the class with %extend or %pythoncode that need to be carried over to Phoenix, such as __nonzero__, etc. Also look for methods where Classic indicates that ownership should be transfered, or other special directives.
• Check for backwards compatibility issues with Classic wxPython and document in the MigrationGuide. Compatibility issues resulting from not renaming all the overloads can probably be left undocumented, we’ll probably be adding some of them back as deprecated methods eventually, and the programmers should be able to figure out the rest once they’ve started porting some code.
• For window classes check if there are other virtual methods besides those added in addWindowVirtuals() that should be unignored.
• UNITTESTS! Create a unit test script in the unitests folder using the same base file name. It should at least check that every non-abstract class can be constructed, and should also have tests for things that are added or tweaked in the etg script. Other things that needed no tweaks are ok to be left untested for the time being, although porting over some of the the old unitest code from Classic would also be a good idea, but priority should be given to testing those things that had to be tweaked or added.

* Win32 Activation Context *

Port the code from Classic that creates the activation context for the process. This is what is needed to make the themed version of the native controls be used instead of the old Win2k style controls. There are a couple tickets in Trac releated to the activation context, so look at those and see if those issues are solveable in the Phoenix verison of the code.

NOTE: Kevin has enabled the activation code that was previoiusly commented out, but the Trac tickets should still be looked at to see if there is a better way that will work for the general case as well as the problems identified by the tickets.

See tickets #12219 and #13275

Exceptions

• Can we convert C++ exceptions to Python exceptions?
• Can we propagate Python exceptions over C++ blocks?
• Should we? (Classic doesn’t.)

WAF Build

• Update wscript to support installation of the wxPython package, either to the site-pacakges dir of the active Python or to a DESTROOT for when building installer packages.
• Can we also do other distutils- or setuptools-like things from our wscript? For example, creating an egg or other standardized python distribution format, uploading to pypi, etc. Or perhaps we can dynamically generate a setup.py script that will do that stuff for us. I’d really rather not have to maintain both setup.py and the wscript that can both do full builds...
• Add support for using the cygwin and mingw32 compilers.

other dev stuff

• Come up with some way to implement the MustHaveApp check that Classic does. It should raise an exception when something is created/used that should not be done before there is an application object.

• Should the functions created for things like addCppMethod be marked static? How about using inline?

• Word-wrap the briefDoc strings used for %Docstring directives

• It looks like the code that is flattening the element nodes to extract the briefDocs is not getting some spaces that should be in there, probably where some tags are being removed.

• For full coverage of what was in the Classic core modules we’ll need ETG files for the following:

  • axbase (ActiveX. Need to figure out best ways to do MSW-only items...)
  • check that all items in _functions.i and _misc.i have been wrapped
  • PseudoDC

• Add wxCHMHelpController (MSW-only)

Python 3.x

If all goes well, only the build scripts and the custom code snippets that deal with PyObjects or use the Python API will need to be tweaked for Python 3.x compatibility. For the code snippets appropriate #ifdefs can be used. SIP should take care of everything else for us. DONE. Yay! See http://trac.wxwidgets.org/changeset/71554

Still to be determined:

• How to handle the Python library code. Should we try to make it all be usable from both Python 2.7 and Python 3.2+? Or should there be two sets of library modules in the package tree and which is used is dynamically decided at runtime in a more or less transparent manner for the programmer?