← Back to team overview

kicad-developers team mailing list archive



I have no objection to remove intermediate status update.
This status activity is less usefull , because computers are now faster
(In fact, it was also something like a debug dialog).

I second that.
My initial investigation into the current issues with KiCad on wx2.8/ Mac indicates that native GUI toolkits are tending towards requiring all on-screen rendering to be done from within a paint event (or similar). This strongly suggests that we rewrite the code in question in KiCad (mostly status updates and 2D redraws AFAIK) to adhere to this.

~/= Marius

The *.brd file loading code also still has UI stuff in it. In a perfect world with infinite man-hours of development time available, we would remove the UI code from there. A recursive descent type arrangement using functions named "Load(.....)" to match the new Save() functions which I added a month ago or so would be nice.

Again, after these are in place, I see being able to link Python on top of pieces of Kicad (library functions), and then a person could write high level operations in Python to load a board, manipulate it, and save it, all without even having to display ANY of it, because there would be no UI code in the Load() or Save() functions.

Just an example would be to change all the silk screen fonts to a given uniform size. (If I am not mistaken, currently fonts can all be different per footprint, and sometimes this may not be desirable). But this is only one example.

(Yet this plan does not exclude the possibility that a Python script would run from WITHIN Kicad, and could be menu invoked, a sort of plug in architecture. )

I just like the "context free" library implementation when we can, because it makes it easier to write things like conversion programs and what not, code which does not need to link to all the program. Conversion programs could use our Load() and Save() functions, that way they remain more independent of future file format changes. Also they could be written in either C++ or Python.

If the UI is kept at the highest levels of the code, this then allows the lower levels to be re-used more easily because they do not have UI dependencies in them.

Dick Hollenbeck
SoftPLC Corporation