kicad-developers team mailing list archive
Mailing list archive
Re: DRC UI
Dick Hollenbeck <dick@...>
Thu, 29 Nov 2007 08:55:23 -0600
Thunderbird 18.104.22.168 (X11/20071022)
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.
I have no objection to remove intermediate status update.
This status activity is less usefull , because computers are now
(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.
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.
From: Dick H., 2007-11-29
Re: DRC UI
From: jean-pierre charras - INPG, 2007-11-29
Re: DRC UI
From: Marius Kintel, 2007-11-29