mirror of
https://github.com/wxWidgets/Phoenix.git
synced 2025-12-16 09:40:07 +01:00
4f7cd6268a
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk@69053 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
200 lines
8.4 KiB
Plaintext
200 lines
8.4 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.
|
|
* Check for any extras added to the class in Classic wxPython and
|
|
evaluate whether the same extras should be added to the Phoenix
|
|
verison.
|
|
* Check for backwards compatibility issues with Classic wxPython
|
|
and document in the MigrationGuide. (This file is still in the
|
|
Classic wxPython source tree.)
|
|
* For window classes check if there are other virtual methods
|
|
besides those added in addWindowVirtuals() that should also be
|
|
added back.
|
|
* UNITTESTS! At least check that every class can be constructed.
|
|
|
|
|
|
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.)
|
|
|
|
|
|
build.py
|
|
--------
|
|
* Get Kevin's wscript?
|
|
* 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.
|
|
|
|
* Add a little code around the running of SIP that tells it to
|
|
write the generated C++ and etc. files to a tempokrary location,
|
|
and then will compare those files with the existing set in the
|
|
sip/cpp folder. If a file has changed then the new one is
|
|
copied over it, otherwise it is not touched. This will help
|
|
speed up builds by not rebuilding a file that doesn't need it.
|
|
* Maybe optionally this could also strip 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.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
Generate 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 effor 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 usign 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.
|
|
|
|
*
|