Phoenix/TODO.txt

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?

  * Add ETG scripts for these items in _core:      
      
      * PseudoDC (not actually an ETG script, probably a .sip)
      * access
      * cmdproc
      * dialup  ??
      * docmdi  ??
      * docview ??
      * filehistory
      * fswatcher
      * msgout
      * palette  ?
      * persist  ?
      * quantize
      * rawbmp
      * richmsgdlg  (requires wrappers for wxGenericMessageDialog)
      * textdlg
      * valgen
      * valnum
      * valtext
      * vlbox
  
  * Add a _msw module that will contain classes and such that are only
    available in the Windows port:  

      * axbase  (ActiveX.  Need to figure out best ways to do MSW-only items...)
      * wxCHMHelpController
      * metafile
      * Any others?

  * Add _grid module
  
  * Add _propdlg module
  
  * Finish _dataview module
  
  * Add _html module
  
  * Add _html2 module  (webview)
  
  * Add _stc module
  
  * Add _xrc module (containg xrc and xml classes)
  
  * Add _gl moodule
    
  * Add _richtext module
  
  * Add _aui module ??  (or go with only agw aui)
  
  * Add _ribbon module
  
  * Add _media module
  
    
    
  
  
  
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?