kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/09/2012 02:55 PM, Miguel Angel Ajo Pelayo wrote:
> Now that may be we're still in time (well in fact, now I think that could be added
> lately without big impact..)
>
>       What do you think about adding a UUID (I see now that you used 'LPID' for SWEET)
> to the PCB files, and also a revision number (that goes incrementally on every modified
> save).
>
>      Also adding LPID to module/footprints would be great, think of the concept for one
> moment:
>
>
>         You could be able to keep your brd files in a database (also distributed), and
> check if your board version is the latest available, even ask for upgrade from kicad.
>
>         Also, with LPID + rev number in the modules/footprints, you could ask KiCad to
> interactively update your footprints from the
> ones you have in the database. For example, somebody in your company could have updated
> certain footprint to enhance manufacturability or fix a silly orientation bug... etc.
>
>        I see a world of opportunities just adding:
>
>             * LPID (or UUID)
>             * File Revision Number (automatical/autoincremental)
>          
>      And also keeping inside the .brd file:  LPID + Rev Number of every module.
>
>
>      I really love this idea, and I see that you already thought of it for sch / lib parts.


Welcome to a 4 year old conversation.  Your conceptual grasp is large.   But the
conversation is old.   I thought about a UUID, but I invested money in an LPID.  Does that
answer your first question adequately?


To summarize my feelings: 


a) what we have in SWEET is revolutionary, since we bring in inheritance, distributed
LIBs, and versioning.  Please watch for bullshit patents popping up on it to help me out.


b) the opportunity and needs in PCBNEW are comparable or greater than in EESCHEMA, I have
tended to think of the task as "bigger than EESCHEMA".  This is a reason why I started
with EESCHEMA, because I was certain that we'd learn things there that would be helpful
when PCBNEW was re-worked.   I have no interest in deviating from this original strategy
because of that single reason.


c) Once you add a logical library name, you can then abstract its implementation and location.


d) Just last week, Jean-Pierre, Wayne and I exchanged emails on bringing in a logical
library name into the *.kicad_brd to better identify the origin of a footprint within a
board.  I think there is support for just this little bit for now.   The prior sentence is
the most important one in this email, please read it again.  Certainly doing more would
require more brain cycles than are available at this time, and can always be done down the
road in PCBNEW.  I was hoping to abstract the library access methodology in the PLUGIN
API, without going to the extent that I am in SWEET.   For s-expression libraries, we are
currently thinking of simply having a directory of s-expression (module) files, rather
than a file of footprints.  So a footprint library is merely a directory.



This is a scouting report, it does not preclude conquering the world at some future
point.  But please realize that my commitment never even extended to even completing SWEET
myself, let alone anything to do with PCBNEW.  Said differently, my SWEET design needs
implementors beyond myself to complete.   SWEET does not apply and cannot apply directly
to PCBNEW, although much that is learned there could eventually be used in PCNEW.


The only reason we are cramming in the new file format now was the avalanche of the
nanometers entering PCBNEW, did not want to disrupt user's lives inconsiderately with
multiple file format changes.


In summary, we are left dreaming and imagining, but get to each a little popcorn while we
are doing it.

My commitments are pretty well documented, and trying to commit resources that I do not
have control over is foolish.

In lose terms, given *current resources* this is what I see:

 PCBNEW minimally ---> EESCHEMA radically ---> PCBNEW better much later


There are many things where we need help:

nanometers:

  UI, DRC, dialogs, zoom, grid, status display of perhaps increasing drill down resolution
as we zoom in. 
  specctra export, gerber testing, etc.


EAGLE PLUGIN:


SWEET HTTP_LIB_SOURCE, which is likely to be a hell of a lot of fun.


Dick