kicad-developers team mailing list archive

[Lorenzo Farina <lf.underscore@xxxxxxxxx>]

Dear developers,

I'm reading with interest this discussion (and connected) about the
improvements you are planning on eeschema (and kicad in general). I'm trying
to underline some elements I felt interesting and to adding my modest
opinion and my limited experience to the brainstorming you're performing.

I spent some time to understand a better way to handle elements in eeschema.
The first things I thought were that 1) the SCH_ITEM* structure is based
upon a pointer list, 2) that we cannot list and modify elements and
properties in tabular form, and 3) that the eeschema program packs every
function in only one executable, thus making the code huge mixing functions
that could have been coded in different applications or at least different
libraries (capturing, bom generation, drc, component/footprint association,
library editor, …).

Even if these assertions are quite off-topic, the above patch trouble
example shows where the problem resides. Kicad needs to be written thinking
that it is collaborative. A user should be able to introduce most new
features without changing most core files, if the code structure allows
this. The patch I proposed was huge and probably will break some new
patches. However, this was the only for me to start a possible “new feature
implementation”. At this time it is quite hard to talk about something
without seeing a possible implementation. I can rewrite it from the starting
point now, and submit patches step-by-step, but with a precise target now.
Until the actual behavoir is kept, main developers will be constantly asked
to consider complex patches that may break the code in some way, wasting
most of their (precious) time.

IMMO, a good way to break the actual glued code would be the implementation
of a standard database structure, capable to perform queries, to be loaded
in memory and being shared within applications if necessary (without doing
complex db server installation and initialization).

External applications (or library components), loaded whenever necessary,
could access the database and perform tasks on elements just knowing the
tabular structure of data. This should ease the DRC process, the BOM, the
file saving and opening process, the library editing, etc... Some other
functions could be easy to be implemented, such as an automatic document
generator based upon template files, an arbitrary component property editor
(distributor, code, price, …), connection with database of already used
components, converter from other file formats, and so on...

There are several in-application databases that are capable of doing this;
one (solid) example:

http://www.oracle.com/technetwork/database/berkeleydb/overview/index.html


 Another personal opinion is that, at this point, the language and framework
chosen is not the main issue. If things are well written and documented, the
code should be easy to read and modify even using a verbose language such as
C++ and a framework that is “dirt” by definition (I said “dirt” because of
the way multi-platform code is handled; conditional compilation makes the
code this way; however wxW is well written and growing fine, and the fact it
is native on most platforms and not copyrighted by any commercial company
has its own advantages). If bugs are found in the way wxW handles some
functions, a discussion with wxW developers is a way to “contribute to the
code you are using”, with little effort. Note that with the 2.9.1 release
(and probably 3.0), wxW is adding several features, that are helpful for
both developers and program stability, and it is considerably easier to use.
Kicad compiles fine on this version (with an issue related to translation
catalog charset, if not already patched), but could take advantage from new
features.

The last thing I need to say is that the different applications (mainly
eeschema and pcbnew) should be separated. A shared folder could be used with
success, whenever generic features are needed (toolbar editor, message
boxes, error handling…). But if you need to place in the “shared” library
something that is used only by one application or, in general, when you have
to switch to this folder while you are not modifying the appearance of
generic elements, it is usual an indication that separated code would make
things better.


 I hope to add something to the things that you already said,


 Best regards.


 Lorenzo