mirror of
https://github.com/wxWidgets/Phoenix.git
synced 2025-12-15 17:20:07 +01:00
ca4746f13c
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk@70205 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
291 lines
12 KiB
Plaintext
291 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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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?
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|