High level features
Better default property handling, possibly cutting some cruft from
generated source by omitting unchanged defaults.
Native design time sizer support. I ran into a hitch while doing the
collection editors. Currently only one type of collection insertion
method is supported e.g. wxToolbar.AddTool().
Sizers need various methods and will be done as soon as I overcome this
Menus will then also support sub-menus and separators.
C++, Makefile support. Personally I plan very basic support and hope
that someone else will take this further. This should expand into
useful facilities for extension writing.
Template for threaded wxPython app?
Update Shell to use wxPython shell.
There should be more interaction possible between your source and
generated source, your objects should be allowed in generated code
at worst these properties should just become inactive or grayed out
while in design mode.
Use tuples instead of wxSizes/wxPoints internally, tuples are much more
- Last sucessful action or error should display in status bar pref with
- More actions should use the progress bar
- Use Idle extensions
- Add toggleable action type
- Refreshing should not delete editor undo history, the update model need changing
- Parameter tips
- Bold current parameter
- Code completion
- Show wx* parent objects methods
- Code parsing / generation
- Should generate/understand multilined code
- Better find / replace dialog
- General purpose wxStyledTextCtrl settings editor dialog
- Look into possibly extending wxApp's stdio redirection to speak to boa
- Hard code white as background for Views with images until masking
is sorted out.
- Change run/debug/compile to be methods on the model, not the source view
- Goto CVS file from Open Module
- Debug browsing should underline the word and all leftside sections
- Save modified date when opening, check filedate before saving, incase
is was saved by someone else.
- Stack trace should remember executing directory for relative filepaths
- wx methods help: From Inspector while on property
- Tag matches in results from search to be able to jump to the next match
in a file. Also have to tidy up colouring so that only text outside <>
are coloured. This currently breaks some links.
- Use wxHtmlHelpControllers
- Add functions to documentation
- Option: Don't print empty sections
- keep formatting like with module docs
- Move method up/down actions
- Switch to explorer view in the class and focused on the
- Optional sort on tree
- Remember which nodes are open and reopen after refreshing
- Replacing FTP completely with http
- Zope does not need zserver or ftp setup
- Firewalls etc.
- Not limited to 3 types (document, folder, system obj)
- FTP is very quick
- Might need more than one call per folder while browsing
- Don't know how to find out which of a list of item is folderish
I do not want to do a query on every item in the list!!!
- Editing ExternalMethods and PythonMethods' Python source in the Editor.
- PythonMethods must be implemented over http, they don't support an
- ExternalMethods should be loaded from the local filesystem,
ExternalMethods don't support properties (why??) and except for parsing
HTML, I don't even know how to access their info
- Uploading images/files
- Move up, move down
- Emulating the mainloop
- Breaking into running code??
- Jump to should not place jumped to line at the top
or bottom of source page, at 5 lines from top or bottom
- Multi selection delete in watches
- Closing with open debugger crashes
- Debug browsing should eval selection (this conflicts with
execution point line selection)
- Make view scrollable and size able
- Some form of zooming (25%, 50%, 75%, 100%)
- Simple caching for slow connections
- Synch Explorer operations like moving files around with
any open applications
- Check file operations against open modules
- Connect opened module if possible to an open app module
- Bind backspace to folder up, F2 to rename
- Bind Insert to New menu
- Better initial sizes for a few controls
- Conflict resolution editor integration
- Accept, Reject
- Update/Commit/Diff from SourceView
- Visual interface to set options
- Update open modules if a cvs operation modified an
- CVS update/diff/commit support
- Import needs to setup masks for recognised file types
- App may not have wxDialog as main frame because an app object
does not quit with dialog as main frame.
- Enable/Disable toolbar buttons depending on state
or only show applicable buttons (not enough space for all btns)
- Boa will stay 1.5.2 compatible until at least the end of
2000. Will consider using new language features then.
- Already using some new Python 2.0 modules (ConfigParser, zipfile)
- wxDialogs should use wxDialog intead of wxFrame
- Add Palette as Popup menu. e.g. New->Container/Layout->wxPanel
- Bind Inser to Popup New menu
- Cursor keys should navigate thru controls
- Incremental typing lookup on wxListCtrl, hopefully in a base class high up :)
- wxPython IDE with visual frame designer
- Working debugger
- Layout editors
- Integrated source control (cvs)
- Zope Support
- Database support
- DB Aware controls
- One possibility is hooking a db aware control
framework to the ZODB
- C/C++ extension writing and possibly debugging support
- wxWindows C++ code generation (maybe)
- Distutils/Installer distribution packaging
- Help projects
* Expand ExploreView to show params & method next to tree
* Move selection to method
- Input: selection, method name
- Process: Identify local variables
Pass vars as parameters
* Extract common expression
- Input: common expr (selection), source (selection), new_name
- Process: Find all occurences of common expr in source
Add initialiser above first use of source:
new_name = common_expr
Replace occurences with new_name
* Renaming of Classes/Methods/Functions/Modules within an app,
- This seems incredibly hard to do 100% correct given Python's
dynamic nature, but there are interesting possibilities in
post mortem inspection of profiler statistics.
With a thorough test suite an accurate log of all every
access to a certain function is recorded.
This leads to...
* Testing facilities, how should GUI classes be tested?
- Window scraping sucks!
- Look into PyUnit
- Methods (as opposed to event methods) could be tested with doctest.py
another Tim Peters module :)
Maybe it can be extended to handle events as follows:
- List of events that can be posted and assertion of certain
control values after posting
I am not very optimistic about this route as none of my own GUI
objects seem testable in a few lines and usually depend on other
frames being open/initialised. Nevertheless this needs to be
pursued and at least those that are testable should be tested.
* Code tools/shortcuts
* Expand creation params:
def __init__(self, param1, param2, ...):
def __init__(self, param1, param2, ...):
YourClass.__init__(self, param1, param2, ...)
self.param1 = param1
self.param2 = param2
* Window id registration:
[wxID_*, ...] = map(lambda i: wxNewId(), range(n))
* Event creation:
EVT_*(self, id, self.OnEvtFunc)
def OnEvtFunc(self, event):
* Update attibutes in uml
Look at Idle's class browser source parser and Idle extensions
Handle more than one class per source file
Add inheritable components
Add revision entry frmt:
# Revision 1.23 1999/08/03 20:49:05 riaan