95 lines
4.1 KiB
Plaintext
95 lines
4.1 KiB
Plaintext
|
|
Here are some source code maintenance tasks that need to be done, and maybe some
|
|
folks will see these items and volunteer to do them.
|
|
|
|
|
|
*** improved xpm handling
|
|
We should:
|
|
1) make a library out of ALL the xpm files, and
|
|
2) develop a simple header file which declares ALL of them using conventional C/C++:
|
|
extern char * somename2_xpm[];
|
|
extern char * somename3_xpm[];
|
|
:
|
|
:
|
|
This way the linker can bundle in the xpms that it has seen referenced. I don't
|
|
think seeing the extern declaration is cause to do this, it must actually be
|
|
referenced. I think this would be an easier way to manage xpms.
|
|
|
|
|
|
*** @todo: grep for @todo and finish off those tasks, scattered throughout the source.
|
|
|
|
|
|
*** use BOARD_ITEM::MenuIcon() in the onrightclick.cpp
|
|
|
|
|
|
*** rework zones so they are modifiable and so that the user does not
|
|
need to enter tracks for thru hole pads or vias which connect to a zone.
|
|
I propose a two step solution:
|
|
1) interim enhancement: make zone edges retained in BRD file and make the
|
|
edges editable.
|
|
2) final solution: get rid of requirement for tracks buried within a zone.
|
|
Reivew the GEDA source code and other sources to gather ideas before doing 2).
|
|
|
|
|
|
*** Use DOXYGEN compatible comments on member functions. As configured,
|
|
Doxygen gives priority to comments in header files over *.cpp files.
|
|
Review the generated docs and start to go through the source and make the
|
|
generated doxygen docs readable and clear using the JavaDoc style comments,
|
|
mostly in the header files. The error and warning output of the doxygen
|
|
compiler can help with this too.
|
|
|
|
|
|
*** Translate comments that are in French to English so there can be a broader
|
|
understanding by new developers.
|
|
|
|
|
|
*** Add tooltip text to all non-obvious controls in every dialog window.
|
|
Need to do this using DialogBlocks.
|
|
|
|
|
|
2007-Nov-30 Assigned To: nobody
|
|
asked by: Dick Hollenbeck
|
|
================================================================================
|
|
wxString DateAndTime()
|
|
It seems the above function should be using a more user friendly "local time",
|
|
not gmtime.
|
|
|
|
|
|
2007-Nov-4 Assigned To: dick, but probably not til January.
|
|
================================================================================
|
|
Enhance DRC dialog box to:
|
|
1) retain lines of error text, so as user re-enters dialog, the previously found errors persist.
|
|
2) support double or single clicking a text line, and have the pcbnew cursor go to the offending marker.
|
|
3) use color in the text line display.
|
|
4) use tooltip on a per line basis, which would show a generic, but error type specific
|
|
message about the error for that line.
|
|
5) Use sizers properly so that as the dialog box is resized, the text area gets
|
|
all the additional space, both horizontally and vertically.
|
|
6) The initial size of the dialog needs to be big enough to show the text lines
|
|
in a clear way.
|
|
7) Add a delete button so user can remove a single line of text after he fixes that track. The delete button
|
|
should also delete that single marker.
|
|
--------------
|
|
Implementation Ideas: retain all drc wxStrings in a vector<wxString> so they
|
|
can be re-displayed again on another popup of the dialog. Switch from wxTextControl
|
|
to wxHtmlListBox for the errors. Add parsing and formatting functions to allow
|
|
grabbing of the coordinate of the marker out of text, and to parse a generic
|
|
error message such that it can be embellished into html for use in the html
|
|
line, such that we can get color. There may be a requirement to rework the
|
|
generation of the drc error strings to facillitate easy parsing. Although
|
|
maybe we use structures instead of strings for error reporting so the parsing
|
|
does not need to happen.
|
|
http://www.wxwidgets.org/manuals/2.6/wx_wxlistbox.html#wxlistbox
|
|
The events given to wxHtmlListBox are the same as wxListBox, so the double
|
|
click handling should be easy, plus there is the added benefit that the wxHtmlListBox
|
|
does not own the strings, it asks for them one by one, so this makes it possible
|
|
to keep the errors in struct form and generate html strings or normal strings
|
|
when needed, on the fly.
|
|
|
|
|
|
|
|
2007-Nov-4 Assigned To: nobody
|
|
asked by: jp Charras
|
|
================================================================================
|
|
Use the collector classes in eeschema.
|