mirror of
https://github.com/wxWidgets/Phoenix.git
synced 2025-12-16 09:40:07 +01:00
0e2a0393b8
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxPython/Phoenix/trunk@69145 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
257 lines
11 KiB
Plaintext
257 lines
11 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.
|
|
|
|
|
|
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.
|
|
|