Adding a wxPython/wxWidget class to Chandler

Draft 1.5

David Surovell

Chandler GUI Frameworks Engineer, OSA Foundation

27 June 2005

Overview

Recognize that the procedure described below needs to be applied to every new wxPython build integrated into Chandler until the new wx class is accepted into wxPython/wxWidgets!

File Manifest

• modified files
  • files.bkl, setup.py, makefile (for RELVER bump), makefile.in, makefile.vc

• new source files
  • all of the new "(classfilename).[cpp,h,i]" files

• new autogenerated files (not to be checked in)
  • one new "wx/wxPython/src/(platform)/(classfilename)_wrap.cpp" file
  • one new "wx/wxPython/wx/(classfilename).py" file
  • all new "wx/wxPython/src/(platform)/(classfilename).py" files
  • others - see "Questions" section

Coarse Tasks

• download and install bakefile as needed to update "makefile.in"
  • platform-independent - easiest on Windows
  • check results by doing diff with current version
  • remove bad blank lines as needed - see "Questions" section
  • get it here
    
    
    
    
• make sure that the "wx/Makefile" has SWIG enabled

• choose a "classfilename" consistent with wx naming schemes:
  • "wxColumnHeader" (C++ class name) --> "colheader" (classfilename)
  • use consistent filenames for all "cpp,h,i" files
    
    
    
    
• create a "(classfilename).i" file for your exposed APIs
  • refer to existing wxPython sources and choose one as a template
    
    
    
    
• place your "(classfilename).[cpp,h,i]" files in the "appropriate" locations inside internal/wxPython-2.5
  • wx/src/... (generic and platform)
  • wx/include/... (generic and platform)
    
    
    
    
• update "setup.py" - add (copy and use as a template) the following 3 blocks:

• update the bakefiles

• remove the two lines in "makefile.vc" (line 3540 or thereabouts)

• rebuild wx
  • search the build output for the target classname files to verify that they were sucessfully incorporated and built
  • be sure to build with "USE_SWIG=1" on each platform and check in the generated files:
    • there is a different set of generated *_wrap.cpp and *.py files for each platform !
      
      
      
      
• test/demo your new widget
  1. wxPython
     • verify importability
       • build/RunPython - import wx; import (classname); invoke routine
     • if the widget is a UI widget, then create a demo that can be invoked from Robin's wxPythonDemo
       • find an existing widget similar to your new one, then use its' "demo.py" file as a template
       • add a single entry to "main.py" for your widget
         
         
         
         
  2. wxWidgets
     • the following is required for wxWidget checkin acceptance;
     • it is optional for Chandler acceptance
       • create a wxWidget demo - use existing copy as a template
       • build documentation files
         • contact John Anderson about tools, techniques and other tips
       • create diff patch file from official wxWidgets CVS
         • submit it via SourceForge

• bump "RELVER" in "wx/makefile", check everything in, and roll a new tarball
  • talk to Heikki or David (me) about how to do this

• add your chandler Python changes and check in separately
  • let's caucus if the separate check-in is impractical

Questions

1. are there any other files that need to be checked in?
   • for example, "_(classname)_rename.i" ?? (assuming "yes")
     
     
     
     
2. should we turn on SWIG permanently?
   • currently, SWIG is turned on temporarily to generate and harvest the "(classname)_wrap.[cpp,py]" source files
   • CLOSED - as of 01 March 2005, SWIG is enabled permanently
     
     
     
     
3. modify "internal/wx/Makefile.in" by hand - y/n?
   • CLOSED - no: this is exactly what bakefile is used for!
     
     
     
     
4. why does bakefile inject blank lines into "makefile.in"?
   • I had to remove 3 of them between lists of source and object files !!!
   • CLOSED - appears to be the result of emailing the file !!!