kicad/todo.txt

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


*** make the ADD_MENUITEM macros in include/macros.h be static inline functions instead
of macros.  e.g. w/o argument types:
static inline void ADD_MENUITEM(menu, id, text, icon)
{
    wxMenuItem * l_item;
    l_item = new wxMenuItem(menu, id, text);
    l_item->SetBitmap(icon); menu->Append(l_item);
}


*** 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-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.