kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> Maybe another thing is to split it complete from the kicad core. So
> create a real library written in ISO C++ so people who want to write
> plugins and language bindings will be more happy than the hacked code
> to read and write files in the current codebase. Because if you find
> some software which can do something with the kicad file formats they
> all write their own parsers/handlers and that is a bit of a pain to
> keep the other people updated for the new upcomming file format(s).
> Also if you dont use any existing library be used in your library like
> wxwidgets it is portable to everywhere and also for people who want
> something different than wxwidgets like Qt/Gtkmm etcetera. Than you
> will see much more tools and utilities than now.
>
> Maybe you should have a look how dxflib and podofo pdf library. Then
> are very powerfull libraries and very consistent with names and
> classes. In my opionion this is a pre for a new file format
> reader/writer.
>
> Kind regards,
> Jerry Jacobs
>
>   



I have also favored this idea for years, and it goes like this:


PLAN A:
======
Ideally, long term, the file 1) reading, 2) writing and 3) ram
data-tree, could be done in a *.DLL/*.so file that is then dynamically
linked to from upper UI code, even for the eeschema executable. 

The shared foundation code (*.DLL/*.so) would avoid all UI code.  In
fact if you had to link it against wxwidgets for anything but wxString,
you probably missed the described design target.  Any need to
communicate errors up to a UI layer could be done with exceptions, and
those could be caught and dealt with in the main executable.

To enforce this during the coding phase, I would probaby not even use
wxString, just to avoid linking to wxWidgets at all.  Then at the end
switch over to wxString once the DLL was known to be free of any UI
code.  The transition would be done by a reassigned typedef or mapping
class back to wxString.  I think to handle text in a way compatible
between the two coding realms (UI-less library, and upper application),
you have to have a common string class.


There are a number of questions with this plan:

1) Written in C++, can you create a layer for each language binding to
the languages that you want?  (I would not help write it in C, nor would
I ever want anything to do with it if it were written in C.)

2) Does this expand the API to the point of huge, because you have to
expose models of all objects contained in the data-tree for all
supported languages.

3) Can you avoid C for the most part and still do the language bindings,
limiting C's presence to very few source modules?



On balance I think the problems that this PLAN A solves are getting
smaller, and so we have to look back at the original problems and
re-measure them in the face of the new file formats.  So let's talk
about PLAN B.



PLAN B:
======
We recognize that with a new set of DSN grammars, we might as well be
talking about something very analogous to XML, but nicer looking and
with no distinction between elements and attributes.  Most languages
deal best with XML on their own terms, they have parsers and data trees
in the language, optimized for the language.  It would not be very hard
to duplicate the generic functionality of DSNLEXER in say python or Java
or Perl or Groovy.  In fact there will be a number of *.keywords files
laying around that could be directly imported into a generic DSN
lexer/parser written in a target scripting language.

In summary, plan B is to push the work into each target scripting
language, but with full recognition that with the new file formats this
work is now *significantly* reduced and subject to much code sharing
across the various grammars.  In some cases a common parser could be
used to parse any DSN grammar, in the same way that an XML parser can
parse any XML file without knowing the grammar.  It just creates a tree
of named elements.  An element needs to hold a list of other elements
and also of name value pairs.

This is all made possible by gravitating to the DSN file format (with
unique grammar per file purpose). 

============

In summary, my current thinking is that the problem that PLAN A would
have solved is now smaller with the new DSN formats.  So small in fact,
that it is not worth the work to do PLAN A.  PLAN B becomes the path of
lessor resistance and greater ultimate usability within the target
scripting language.

Having said that, there are some ideas under PLAN A above that could be
used to write (rewrite?) the C++ classes, speaking now of the separation
of UI code, without going all the way of creating a shared library out
of them.


Dick