← Back to team overview

kicad-developers team mailing list archive

Re: P-Cad plug-in


On 06/26/2012 02:23 PM, Alexander Lunev wrote:
> It was suggested to implement pcad2kicad converter as pcbnew plug-in. It is clear how to do this in the case of pcbnew. Even it is clear
> how to do this in the case of eeschema. But it is not clear what to do with translation of P-Cad libraries (pcb and schematic libraries).
> Now there are 4 different modes in pcad2kicad converter: converting pcb design files, converting pcb library files, converting sch design
> files and converting sch library files. Considering the user interface how the converting libraries could be implemented applied to KiCad?
> Any considerations?

Here are a couple of alternative plans for the *Pcbnew* portion of the
problem/opportunity.  The degree of thoroughness can vary because Pcbnew PLUGIN
can be implemented to varying degrees.  If you do not implement a function this is not a
fatal problem.

Elaborate Plan:
a) Implement *all* the functions in PCAD_PLUGIN, especially all PCAD_PLUGIN::Footprint*().

b) Also implement a library table for Pcbnew, see new/sch_lib_table.h and
new/sch_lib_table.cpp as the basis of
some new similar class, but you replace LIB_TABLE::ROW::lib with a PLUGIN* pointer.  This
replaces the Pcbnew library search path design with a library table design.  An initial
library table could
simply be an s-expression text file, like is being parsed for SWEET already.  Could use
that parser as as starting point, its done, it works.

The library table allows concurrent use of PLUGIN::Footprint*() functions from multiple
alternative technologies.  It means you in theory would not need to convert PCAD, *.mod,
*.kicad_mod, or eagle footprints,
but rather you could use and edit them in situ, as if they were equivalently valid
footprints for Pcbnew.

Mid-level Plan:
a) Implement just the Load() & Footprint{Load,Enumerate}() read only type functions.

b) Also implement the library table as above.  But hard code any writing of footprints
back through the new KICAD_PLUGIN.
This basically gives you a read only or edge triggered conversion of footprints, but lets
you access them natively in situ.

Lazy Plan:
a) Implement just the Load() & Footprint{Load,Enumerate}() read only type functions.

b) Use Miguels scripting to convert from PCAD to s-expression both boards and footprints
on the assumption that the scripting housing could simaltaneously manage two plugins.
Read a footprint, write a footprint.  Read a board, write a board.  You bother with
scripting because its going to happen again on the next PLUGIN.

One of the most frequently reported bug reports that has been seen over the last five
years is the library search path.  I don't like that design and never have.
Obviously I have thought that the library table concept is better, since that is what I
had coded for SWEET.  You can actually see it in operation if you single step
through the SWEET test program.  The key to it is the "logical library name".  In Pcbnew
you have something like a shortened library name in the UI already, and it is currently
the last part of the library path.  With the library table, it becomes more meaningful, it
is an index into the library table.

So if you can see the value in the library table concept, it needs to come in even on its
own merits, aside from this discussion.  Once there is buy in for that,
then the Mid-level Plan starts looking pretty doable for footprint access.

In all cases, just having PLUGIN::Load() gives you the BOARD.  So selecting a plan from
above is tantamount to deciding how you plan on handling footprints.



My concept for SWEET does not encompass any full schematic treatment like PLUGIN::Save()
or Load().  I only intended to support part retrieval, and since the major driver was to
get these parts over the Internet, the representation of the part is SWEET text.  This
means that if you were going to convert from a foreign format, you would do it way down
low, and are actually required to return a SWEET string, not actually load it into a C++
structure.  So the design is completely different in the following ways:

a) API requires that SWEET *textual* representation be the returned results.
b) API intends to be REMOTED.
c) Inheritance is supported, we can and want to do small changes to someone else's work,
and this requires text to do it.

It does not contemplate nor address anything to do with full schematic loading.  In fact,
this library could be used by any other schematic tool, perhaps geda.

Since SWEET is not part of EESCHEMA, and SWEET is not a schematic plugin, but rather a
part plugin for a schematic tool, you do have the option of simply creating a new
PLUGIN design for EESCHEMA which only encompasses the full schematic, i.e. Load() and
Save().  Leave the part plugin portion out of it and plan on incorporating SWEET down the


> Best regards,
> Alexander Lunev
> _______________________________________________
> 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
> .

Follow ups