mirror of
https://github.com/wxWidgets/Phoenix.git
synced 2026-01-05 03:20:08 +01:00
1f9c6d88b0
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk@70983 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
299 lines
12 KiB
Plaintext
299 lines
12 KiB
Plaintext
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.)
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
* 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:
|
|
|
|
* taskbar
|
|
* all missing common dialogs
|
|
* print (as in print framework classes)
|
|
* mdi (die mdi! die!)
|
|
* listctrl
|
|
* treectrl
|
|
* dirctrl
|
|
* cshelp
|
|
* dragimag
|
|
* datectrl
|
|
* hyperlink
|
|
* pickerbase, clrpicker, filepicker, fontpicker
|
|
* filectrl
|
|
* commandlinkbutton
|
|
* axbase (ActiveX. Need to figure out best ways to do MSW-only items...)
|
|
* settings
|
|
* sysopt
|
|
* tipdlg
|
|
* check that all items in _functions.i and _misc.i have been wrapped
|
|
* joystick
|
|
* sound
|
|
* mimetype
|
|
* artprov
|
|
* clipbrd, dnd, finish dataobj
|
|
* power
|
|
* overlay
|
|
* PseudoDC
|
|
|
|
* Divide Phoenix core into multiple modules. Perhaps using the same
|
|
divisions that a wx multi-lib build uses would be a good
|
|
idea. OTOH, doing something like what Classic did will make the
|
|
transition easier for anybody who explicitly used the core
|
|
extensions there. OTOOH, keeping it as one big module might not be
|
|
so bad... NOTE: I've attempted to do this split but because of all
|
|
the various interdependencies of the items currently in core I
|
|
wasn't able to make any divisions that had more than a few classes in
|
|
them. So let's go the route of following the wx multi-lib
|
|
divisions, except where it makes more sense for a group of classes
|
|
to have their own extension module like dataview or grid.
|
|
|
|
We will likely need to have a way to export (like with a CObject) some of
|
|
the helper functions in wxpy_api.sip from the core module so they can
|
|
be used in the other extension modules... DONE.
|
|
|
|
* Check wxDialog::CreateTextSizer, is it wrapped?
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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 yet 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.
|
|
|
|
|
|
|