kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/30/2012 11:05 AM, Dick Hollenbeck wrote:
> On 06/30/2012 06:04 AM, Alexander Lunev wrote:
>> 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'?
>
> Can we talk about one program at a time?  Let's focus on Pcbnew, for which the PLUGIN
> interface exists.
> Eeschema is for another day, and I don't think it is pertinent yet.
>
> What you are saying will be fractionally true, with different magnitudes of truth
> depending on the foreign EDA tool, and to the extent that each foreign tool has features
> that Pcbnew footprints do not support in its footprints.
>
> I don't see where rounding of numbers enters into it, since we now go to nanometer resolution.
>
> The greater the compatibility in footprint features, the greater the ability to round trip
> footprints. 
>
> In the case of Eagle, I did not see anything preventing us from writing FootprintSave()
> and FootprintLoad() and actually using Eagle footprints almost as well as they do,
> including editing them.  In situ means "in place".   This means just use eagle footprints
> where they live, say under the Eagle directory elsewhere on your hard drive, no need to
> convert them to a different file format.  Also keep in mind that:
>
> a) because the PLUGIN::Footprint*() functions position the MODULE as the go between
> entity, the design encourages the enhancement of MODULE to accomadate features from other
> EDA tools that we currently do not support.
>
> b) most of the time footprints are read only entities, for if they were not, why in the
> world would the default install of footprint libraries on linux do so into a read only
> directory?
>
> c) If you can read a footprint well enough to convert it, you can read it well enough to
> certainly use it without writing back to disk other than in a BOARD via instantiation.
>
> d) If you can read a footprint well enough to convert it, often you can figure out how to
> write it back out in the foreign format.  Two reasons why you might WANT to do this are:
>    1) you intend to inter-operate with a community of designers using that foreign tool,
> 2) you would like them to eventually feel comfortable enough with KiCad to convert.  This
> is not particularly different than what Open Office has done.  They have supported both
> read and write capability in many different file formats.
>
> e) There is Pcbnew code to load a geda footprint now, if it was put into a PLUGIN, then
> you'd have read only capability to use those libraries in situ, i.e. without converting
> them first.
>
>
>> 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.
>
> I don't know how you get to that above supposition.  If you write PLUGIN::FootprintSave()
> then you preserve the ability of the original EDA tool to use your footprint edits.  This
> is somewhat like when I send a *.doc file to a MS Word using 

oops, user

> that I created using Open Office.
>
>
> The last thing I would say about the value of the PLUGIN API is that it is an organizing
> mechanism for future evolution.  Just by putting code into the slots provided in the
> plublic PLUGIN API, you are making somebody else's goals more achievable later in time.  
> Organized, longer term enhancements become easier.  The Most Elaborate Plan becomes
> easier, incrementally.
>
> The cheapest plan of all is one I did not mention, and that is to inject PCAD_PLUGIN into
> your conversion program, and simply implement as many of the functions in that separate
> executable as you can.  This then becomes a building block for someone more ambitious
> later on.
>
>
> Dick
>
>
>> 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
>> <https://launchpad.net/%7Ekicad-developers>
>>> Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/%7Ekicad-developers>
>>> More help  : https://help.launchpad.net/ListHelp
>>> .
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> <https://launchpad.net/%7Ekicad-developers>
>> Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> <https://launchpad.net/%7Ekicad-developers>
>> More help  : https://help.launchpad.net/ListHelp
>>
>>
>