kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/5/2010 10:33 AM, Dick Hollenbeck wrote:
> 
> I get paid to brainstorm, so brace yourself.
> 
> Continuing with library brainstorming, the following is put on the table
> for consideration and eventual evaluation. Brace yourself, this is out
> of the box.  Open up your mind before proceeding.
> 
> Remember the HTML editors which let you view HTML source and the
> resultant GUI presentation at the same time?  One panel has the html
> source, another shows you its effects.  The following concepts use that
> UI paradigm.  Use the source Luke, use the source.
> 
> 
> A library is not a library file:
> -------------------------------
> 
> The concept of a *library file* is gone.  There are none.  The concept
> of a library can still exist but it is a RAM resident concept.  Each
> component that we traditionally think of residing in a *library file* is
> actually in its own file on disk in a directory (or repo or schematic). 
> A library is only built in RAM during the loading of a collection of
> components.
> 
> 
> Loading components:
> ------------------
> 
> The act of loading components utilizes the notion of inheritance and
> classical file inclusion like the C++ #include.  Let's go back an
> understand inheritance thinking about Java. In a Java virtual machine
> each class definition container has a method table.  That table is
> initially populated with methods from the base class.  As the base class
> is extended some of those methods are overloaded (replaced) with ones
> from the derived class in the internal method table.  Additional fields
> can be introduced in derived classes also, into what is a field table
> for that class.  Now lets move that conceptual model to a component. 
> Lets assume we have a pin table, and a graphics table.  We give a
> component the ability to inherit from: 1) a base code fragment,  or 2)
> symbol or 3) component.  In this case you can do pin additions, or pin
> modifications, pin swapping, in the same way you can overload a Java
> class's method table.  Pins can be overloaded or replaced, and graphical
> primitives can be inherited and extended.

Conceptually I really like this idea from a coding stand point.  If you
are careful you could implement this so that the code maps one to one to
your new conceptual model.  This would make it easier to implement new
features will breaking the existing ones.  The only issue I see is how
to convert existing libraries into the new format or do we abandon
backwards capability and push on towards a superior implementation.

> 
> The magic happens during the loading phase of the S-expressions, so that
> the "built up" component is fully assembled in RAM by using pieces from
> various places "out there", while *loading*.
> 
> If desired, the various pieces can be ear-marked with their origins in
> full recognition of the existence of inheritance.  One might do this
> only to facilitate graphical editing of a derived component, although if
> the grammar is sweet enough, textual editing may be enough for all
> editing of derived components.

I have always preferred a well designed textual editing interface for
creating drawings.  In many ways I find it easier than performing these
operations graphically.  I however probably do not represent the larger
group of users who prefer a GUI editor.  This may be one of those ideas
to have our users group liaison check in with the users group to see how
they feel about it.

> 
> Re-loading is simply done by clicking a "parse" or "show" button.  The
> the parser reloads the source stream and does file inclusions as called
> for.  A portion of that source stream comes from the textual UI panel. 
> Inherited portions come from a library (which is now a RAM resident
> concept only).
> 
> 
> Example
> -------
> 
> (component SOMENAME
>   # inherit is like C++'s #include
>   (inherit SOMEOTHERNAME WHERE)
>   (pin 12 ... WHERE...ORIENTATION)
>   (pin 13 ... WHERE...ORIENTATION)
>   (pin 14 ...)
> )
> 
> Pin 12 and 13 are provided here and they are overloads because 12 and 13
> have already been defined in SOMEOTHERNAME.  So this could be the means
> of a *pin swap*.   However pin 14 is new, since SOMEOTHERNAME did not
> have one, so this is an extension. In one example we see both a)
> overloading and b) extension.
> 
> This example would be a new SOMENAME component, and its graphics are
> fully inherited from SOMEOTHERNAME, and can be extended here, but not
> overloaded in any way that I can think up.
> 
> 
> Where do they come from? and component versioning:
> -------------------------------------------------
> The ability to reference an external component by a GUID (globally
> unique ID) of some kind lets you pull in components from anywhere in the
> world.  A GUID inherently needs to respect versioning.  That is to say,
> if you make an edit to a component that somebody else depends on, you
> still have to provide the original version also.

This is a great idea.  This prevents unwanted changes to your schematic
when the underlying component is revised.  Doesn't Bazaar use the GUID
concept for internally keeping track of revisions?  This would dovetail
nicely into your GUID concept.  Where does this leave the concept of
project libraries?  Do they become a local library repo in project
directory or does all this component information get saved in the
schematic file?

> 
> Enter the version control system.  Since each component and component
> source code fragment exists in its own file, a source code control
> system is used to house these files, and they can be accessed by using a
> SCCS repo, file name and version number, over the Internet, or locally.
> 
> One possibility for this is to build a tcp socket oriented bridge into
> Bazaar's access API, which I assume lets you access any version of any
> archived file.  Only one such server is needed for the "kicad supplied
> libraries".  Behind the scenes the bridge/server simply uses launchad's
> bazaar based repo.
> 
> The loading of code fragments from afar need to be cached in RAM, so the
> concept of a *library* does not go away.  A library is a RAM container
> that caches those things coming from afar in order to enhance speed. 
> But remember, kicad supplied libraries are essentially "read only" (for
> all but those with the generating scripts).  So putting them under SCCS
> and in launchpad as a primary place of dwelling is reasonable for those
> with Internet access.  Others could check out the library branch.

Does launchpad allow you to access repos without SSH keys?  It may be a
bit cumbersome for users to have to create a launchpad ID just to check
out or keep up to date with the main repo.  Maybe we could provide a
guest user ID and SSH key to do this.

> 
> 
> How?
> ----
> 
> I can have this coded by Tuesday, given enough incentive.  (I'm just not
> going to say which Tuesday.)

Do I want to know what "enough incentive" entails?  Seriously though, it
is a neat concept which you obviously have give a lot of thought to and
I'm certainly interested in seeing how this would work.  Please keep me
posted as I still have quite a bit of component library object clean up
work to do.  If you have any questions about any of the component
library object code or if there is anything I can do to help let me know.

Wayne

> 
> 
> 
> _______________________________________________
> 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
>