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, 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 etc. 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? 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. Exceptions ---------- * Can we convert C++ exceptions to Python exceptions? * Can we propagate Python exceptions over C++ blocks? * Should we? (Classic doesn't.) build.py -------- * Update wscript to support some of the same (or similar) capabilities 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. Deprecated C++ items --------------------- * Does Doxygen have a standard way to mark items as deprecated that will also be tagged as such in the XML? wxProgressDialog ---------------- * Add wxGenericProgressDialog. * and wxProgressDialog inherits from the generic version other dev stuff --------------- * data buffer support for wxImage RGB and alpha data * port all of the wx.Bitmap 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. * Should the functions created for things like addCppMethod be marked static? How about using inline? * Word-wrap the briefDoc strings used for %Docstring directives * For full coverage of what is in Classic core modules ETG files are needed for: * filesys, fs_mem, fs_inet, fs_arch (with wxZipFSHandler typedef) * versioninfo * popupwin * tipwin * vscroll * taskbar * all missing common dialogs * print (as in print framework classes) * mdi (die mdi! die!) * scrollbar * toolbar * listctrl * treectrl * dirctrl * cshelp * dragimag * datectrl * hyperlink * pickerbase, clrpicker, filepicker, fontpicker * filectrl * infobar * commandlinkbutton * axbase * settings * sysopt * tipdlg * check for items missing from _functions.i and _misc.i * joystick * sound * mimetype * artprov * datetime, or make it be a MappedType for Python date objects? * clipbrd, dnd, finish dataobj * power * about * uiaction * Divide Phoenix core into multiple modules. Perhaps using the same divisions that a wx multi-lib build uses would be a good idea. Daily builds and releases ------------------------- We now have a buildbot for Phoenix located at http://buildbot.wxpython.org:8010. We should update the scripts so it not only does builds and testing, but also makes distributable binaries so some of the wxPython-dev folks can play with the bleeding edge versions without needing to be able to do full builds themselves. Specifically, we should: * Make sure that Phoenix files are installed such that they do not clobber any wxPython Classic installed files. * Do not install a .pth file so Classic will remain the default "wx" that is imported. * Provide a script that can be run to display the installed versions of Classic and Phoenix and allow the user to select which should be imported by default with "import wx". It will do this simply by writing a new wx.pth file in an appropriate location. It should be able to deal with the path hackery that was used on Macs to allow wxPython to be used with either Apple Python or Python.org Pythons. * Make sure that the selection script can also be used in a virtualenv. On the Mac we may want to enable the script to also do the stuff needed to make the framework Python work correctly as shown at http://wiki.wxpython.org/wxPythonVirtualenvOnMac * To begin with the binaries produced do not need to be very elaborate like Classic currently uses. Perhaps just a .zip file with instructions of how/where to install would be good enough in the early stages, since our target audience at the beginning will be techie users that don't mind the bleeding edge and have the know-how to deal with it. Smarter more capable binaries or installers can be added over time as needed. * The making of a distributable build could simply be yet another command handled by build.py. Perhaps another command can be used to upload the binary to whatever server they will be distributed 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.