kicad-developers team mailing list archive

[Alexander Lunev <al.lunev@xxxxxxxxx>]

Thank you for the comprehensive reply.

On 06/27/2012 02:13 AM, Dick Hollenbeck wrote:
> 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.

As I understand it actually works in theory only. If I ultimately convert some heterogeneous library to KiCad and somehow save it into
new representation, say SWEET, then in most cases I will need to manually correct the new saved library components in order to fit their
drawings in appropriate or better positions because of distortion caused by the conversion (positioning errors, shape approximation etc.)
Moreover I can not imagine how to edit components in heterogeneous library in situ by means of KiCad not spoiling them because of
distortion caused by import/export on-the-fly. Even though you edit the heterogeneous components in situ and manually edit/adapt them to
KiCad, these components will no longer be well representable in the original (heterogeneous) CAD.

Do I understand you right concerning 'in situ'?

Best regards,
Alexander Lunev



________________________________
 From: Dick Hollenbeck <dick@xxxxxxxxxxx>
To: kicad-developers@xxxxxxxxxxxxxxxxxxx 
Sent: Wednesday, June 27, 2012 2:13 AM
Subject: Re: [Kicad-developers] 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
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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> .
>



_______________________________________________
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