kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/12/2010 7:15 AM, Lorenzo Farina wrote:
> 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.

Lorenzo,

You have hit the wall that most developers run into when hacking on Kicad.
There are still a lot of places where the object encapsulation is very weak
making very difficult to add new features without breaking something else.
When you have the UI code and the low level object code directly manipulating
each other all over the place, you will always have this problem.  When you run
into this situation, you should fall back and clean up the low level object
code first then add your new implementation.  This has the added benefit of
making it easier for the next person who comes along.  I know this is not the
most glamorous way to contribute to Kicad, but it is probably more important
than the next feature that adds to the complexity.  Maybe you can be like me
and have negative number of lines of code contributed because you've delete
more lines of code then you have added :).

> 
> 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

I would have no issue if you wanted to provide SQL import and export of BOMS
and other tabular data structures in Kicad.  I do have an issue with actually
using a database to store this information within Kicad.  Plain text files
provide so many advantages over a database for the way Kicad saves and loads
it's data structures.

Wayne

> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp