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. 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. (This file is still in the Classic wxPython source tree.) 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 also be added back. * 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. Handling the GIL ---------------- Currenlty nothing is set for how to deal with the GIL, so there is no release and reaquire happening yet, meaning that threads will be blocked while control is in the C++ code. There are some possibilities to be considered. * Classic wxPython would wrap **every** call to a C++ function in GIL release/reaquire code. Later on I added the ability to not do that for specific classes or methods (those known to not block, take a "long" time, or that could result in a callback.) This likely missed many places that could have benefitted from not dealing with the GIL. Should the same approach be taken with Phoenix? Or should the default be to not release/aquire the GIL and we'll have to turn it on for classes or functions that need it? If so we could automatically turn it on for Window classes and that would probably take care of most of the places that must have it. * Take a look at what SIP does when it makes callbacks for virtual methods. We'll need to do the same thing in the EventThunker and anywhere else that we're doing callbacks ourselves. NOTE: Currently there is some Classic code alread in use there. I need to at least verify that it is doing the right thing... * Can we reuse the GIL handling functions from Classic wxPython or do they need to be rewritten? Exceptions ---------- * Can we convert C++ exceptions to Python exceptions? * Can we propagate Python exceptions over C++ blocks? * Should we? (Classic doesn't.) PyAssertionError ---------------- Implement the ability to raise an exception when an assert in wx is triggered. SIP ---- * Patch SIP to remove leading space from %Docstring items? Not really needed but will help our generated .sip files be more pretty and easier to read. I've asked Phil about it and so far he seems a bit reluctant. "Sip has no business messing about with the user's text formatting." build.py -------- * Update wscript to support some of the same (or similar) options we have with setup.py. * Change from using a --waf option to being a "waf" command like the other build.py commands, and assume that any other items on the command line after the waf command are to be passed on the waf command line when it is run. If there are not any other items on the command line then use a default set of waf commands. * When writing generated C++ files from the temp dir to sip/cpp allow optionally stripping out the lines starting with "#line". Those are handy when we need to step through code in the debugger, but could cause differences in files that are otherwise identical to their prior version, which means some unnecesary rebuilds. etg/pen.py ---------- * Add new implementations of Get|SetDashes that use wxArrayInt. SetDashes will likely need some black magic like what was done in Classic wxPython. etg/menu.py ------------ * Figure out what to do about the MSW-only methods in wxMenuItem wxProgressDialog ---------------- * Add wxGenericProgressDialog. * and wxProgressDialog inherits from the generic version Generated Unitests ------------------ * Autogenerate a skeleton unittest module for each etg module. * It can traverse the items in the module object and use a test template based on what kind of item it is. Templates could include toplevel window tests, non-toplevel window, event binder, event class, etc. * If the file already exists then don't overwrite it. Or perhaps we could have a "# AUTOGENERATED" tag in the file that means that it can be overwritten. If a human wants to take over the file and add additional tests then they just need to remove that tag. Deprecated C++ items --------------------- * Does Doxygen have a standard way to mark items as deprecated that will also be tagged as such in the XML? custom wrapper code ------------------- Currently function.setCppCode requires some sip-isms (using sipRes and sipCpp for example) to be able to replace the wrapper code used to wrap the C++ function. Try making it work more like addCppMethod where it will generate a new function that is passed "self" and that you can simply return a value from. Namespace Diff Tool ------------------- I think that this will be more than just a diff tool, but for now that is the only name that comes to mind. The general idea is that the tool can be used to help us discover differences between different versions of wxPython, such as Classic vs. Phoenix, or even between different iterations of Phoenix. The tool would be used to help us identify what is missing and still needs to be implemented, or what is new, etc. The granularity would be items at the module level, and items within each class, such as methods and properties. I don't think it would be worth the effort to compare things like function signatures or docstrings because the effort to do that may be large. But maybe it could record whether a docstring is present to help us track down items that need them added. Here is a basic workflow and any other ideas that come up along the way: * Since the tool will be dealing with multiple versions of wxPython (although nothing should prevent this from being used for other packages as well), including historical versions, then the tool will not be able to do a live introspection and compare. Instead it should be able to do an introspection and source analysys of a specified package and record the results in a database or perhaps an XML file. The things it should be able to record are the package/module names, the names and perhaps the types of all top level items in a module, the names of all items in each class, whether modules, classes, methods, functions have docstrings, etc. * The scan and analisys should recursively descend to include all modules within the specified package. Any imports of packages or modules located outside of the target package can be ignored. * When the scan is finished all the data can be saved using a specified name. (The name can be used to name the XML file, or be used to collate all data related to this scan in a sqlite database if that is what is used to save the data.) * The tool should be able to be used to answer questions about the data for a single scan like: * number of classes * list of all class names * list of methods in class Foo * count or list of items starting with "EVT_*" * list of items without docstrings that should have one * etc. * Once there are more than one scan saved then the diff tool can be used to highlight differences between them, such as the classes in scan A that are not in scan B. The methods that are in the Foo class in scan A that are not in the Foo class in scan B. Etc. * Since it is expected that some things will be missing on purpose there should be an easy way to tell the tool that when comparing scan A and scan B, or perhaps when comparing scan A with any subsequent scan, that it should ignore the fact that item X is missing and not report it. other stuff ------------ * wxComboBox: why are GetSelection. SetSelection and IsEmpty overloads being ignored? * wxListBox: All "Set" methods ignored, why? * textctrl: wxTextEntry and wxTextCompleter are in separate files * textctrl: add a renamed HitTest row/col overload * Figure out how to handle the global stock objects, like wxBLACK. * data buffer support for image RGB and alpha data * port all of the wxBitmap copy-to and copy-from buffer methods, and raw bitmap access routines from Classic * 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.