56 lines
2.0 KiB
Plaintext
56 lines
2.0 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
|
|
|
|
|
|
*** 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);
|
|
}
|
|
|
|
|
|
*** Set up a DOXYGEN environment starting with a configuration file that:
|
|
- understands the JavaDoc style comments that we have started using
|
|
- gives preference to comments in header files over *.cpp files
|
|
- outputs its HTML stuff relative to the base of trunk, say for example trunk/doxygen
|
|
- is then added to the svn repository (this configuration file only)
|
|
Then add a shell script and batch file to generate the docs using the config file.
|
|
Then 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.
|
|
|
|
|
|
*** Implement the graying in/out of "Edit/Undo", "Edit/Redo" menu items,
|
|
when Undo/Redo stack is empty/filled.
|
|
|
|
*** There is no way to truly edit a via, such as changing its layers.
|
|
|