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 <d...@softplc.com>
>> *To:* kicad-developers@lists.launchpad.net
>> *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@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>>> 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@lists.launchpad.net
>> <mailto:kicad-developers@lists.launchpad.net>
>> 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
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
