forked from wxWidgets/Phoenix
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO.txt
167 lines (113 loc) · 5.6 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
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.)
WAF Build
---------
* Add support for using the cygwin and mingw32 compilers.
other dev stuff
---------------
* 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.
* Locate and/or add items for the various functions and things in Classic's
_functions.i module.
* Add ETG scripts for these items in _core:
* PseudoDC
* msgout
* quantize
* dialup ??
* docmdi ??
* docview ??
* palette ??
* persist ??
* Add a _msw module that will contain classes and such that are only
available in the Windows port:
* axbase (ActiveX.)
* wxCHMHelpController
* metafile
* access
* Any others?
* Add _propdlg module
* Add _aui module ?? (or go with only agw aui?)
* Add _ribbon module
* Add _media module
* Add the UTF8 PyMethods from classic (see _stc_utf8_methods.py) to StyledTextCtrl
* Reimplement the classes in the valgen, valnum and valtext headers as
Python code, and make them visible in the core wx namespace?
* Should the demo/version.py file be maintained in the source repository?
Or just let it always be generated like wx/__version__.py?
* Should demo/Main.py ignore anything in the version strings after the '-'
when comparing?
* Finish richtext module
* Potential reference count issue with wxGridCellCoordsArray? Code
like this::
theGrid.GetSelectedCells()[0][0]
evaluates to garbage values, but this works fine::
a = theGrid.GetSelectedCells()
a[0]
a[0][0]
* In a Py3 build strings like wx.TreeCtrlNameStr are being generated as
bytes objects, they should probably be string objects. Or not, sip's
default might be best... See ModuleDef.addGlobalStr if I change my mind.