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
architecture
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.
================================================
EESCHEMA
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
line.
Dick
>
> Best regards,
> Alexander Lunev
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
> .
>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
