kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

I just want to give everyone a heads up, I just committed my changes to
SVN. You will need to do a "make clean" first or you will get a bunch
of multiple definition errors from the linker do to the global variable
changes. I am not sure I covered 100% of the code paths with the new
library search implementation. Let me know if you find any problems and
I'll try to fix them as soon as I can. I'll be pretty busy over the
next two weeks so I may not be able to respond the same day. Thank you
for your patience.

Now as promised, I have a few issues I would like to see addressed as
the project moves forward. Before I start, I want to thank everyone for
their hard work. I just finished a board at work using latest release
of Kicad and I am very pleased with the progress Kicad has made. Ground
planes using the new polygon code come out very nice compared to the
segment based code. Also, these suggestions are in no way a criticism
of anyone. I realize that a lot of the code in Kicad is legacy code. I
am willing to work on these problems. I just want to make sure we are
in agreement so I don't have any of my work discarded. Without further
ado, here is my wish list from most to least important.

Using non-standard colors in dialog box button text and fonts in dialog
boxes looks amateurish in my opinion. I violates the users chosen
widget theme on platforms that support themes. Every UI design guide
frowns upon this type of design. Unless there is some usability reason
to change the dialog font and text colors, please don't do it. My
original changes to the annotation dialog removed them. They have since
reappeared. I think this would go a long way to making Kicad look a bit
more professional and platform neutral.

I counted over 200 global variables in my travels through the source
code. I can understand a few here and there not 200. This is the
reason many of the settings in Kicad don't get saved and restored
correctly. They get copied back and forth (or forget to get copied) to
a local variable. This is a recipe for disaster.

Can we drop the one giant case statement command event handler
mentality? This is how it was done before C++. It also creates a lot
of headaches when adding new event handling code. Event tables in
wxWidgets are design simplify event handling. Grouping events together,
just complicates things. Unless events are related like the grid size
or zoom level events, please use a separate event handler. I know this
creates a lot of small functions. This is a good thing. If I have
learned nothing after 21 years as an engineer, is that simpler is almost
always better.

Stop handling menu, toolbar, and other UI updates in event handlers, use
EVT_UPDATE_UI() instead. This causes some of the problems on GTK when
the toolbar buttons do not get disabled until the mouse is moved.

Fix the hot key implementation. The current hot key design is broken.
Because it is effectively an event handler inside and event handler,
wxWidgets doesn't know anything about it. It should just be a
configurable wxAcceleratorTable(). Now keystrokes get handled just like
any other command event. I know there is a problem with GTK and
alphanumeric keys without a modifier key. But the problem is easily
solved with a few lines of code in the character event handler to fix
the problem.

Stop duplicating code. I found that the PCB footprint module file
parsing code is implemented at least twice. Once in PcbNew and once in
CvPcb. This is really bad. if change the file format you have to
remember to change both pieces of code. This need to pushed into a
common file parsing class and used any place the footprint files need to
be parsed.

Don't reinvent the wheel. There is a lot of code in Kicad that is
already implemented in wxWidgets and typically not a well. Just look at
some of the changes I made using wxFileName and wxPathList. If the
default implementation in wxWidgets doesn't have everything you need,
just derive a new class from the wxWidgets class and add the new
functionality. Don't write a whole new class just for one or two new
features.

Try to used wxWidgets the way it was designed to used. wxWidgets has
some excellent features that makes life easier for developers. But it
only works well when you fit it into the way wxWidgets is design. If
you add wxWidgets as an after thought, you will have real mess on your
hands. Take a look at Kicad's PostScript output code. If the Kicad
drawing code used wxDC correctly, adding PostScript support would have
taken a few lines of printer setup code. Take a look at the
wxPostScriptDC source to see a great example of how any device context
code should be done. If Kicad needed any special PostScript code, that
should have been done by deriving from wxPostScriptDC.

Thats all for now. As I have said before, I am willing to work on as
many of these issues as I can. I just want to make sure I'm heading in
the right direction. I know from experience that if my objectives are
too far from everyone else's that I will get nowhere but frustrated and
that my efforts will frustrate everyone else. And that is definitely
not my goal.

Best Regards,

Wayne