kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/08/2013 05:43 PM, Chris Morgan wrote:
> On Thu, Aug 8, 2013 at 6:09 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
> 
>     On 08/08/2013 04:44 PM, Chris Morgan wrote:
>     > On Thu, Aug 8, 2013 at 12:12 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>
>     > <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>     >
>     >     On 08/07/2013 05:25 AM, Chris Morgan wrote:
>     >     > On Tue, Aug 6, 2013 at 9:50 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>
>     >     <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>> wrote:
>     >     >> On 08/06/2013 06:40 PM, Chris Morgan wrote:
>     >     >>> Hello.
>     >     >>>
>     >     >>> Sites like http://www.kicadlib.org/ are great for sharing libraries
>     >     >>> but I was thinking that having integrated online library sharing could
>     >     >>> better distribute the work while making it easier to share and use
>     >     >>> parts. A user could add add trusted sources to their remote libraries,
>     >     >>> contribute new parts, vote on parts etc.
>     >     >>>
>     >     >>> Thoughts? It would probably take a bit of effort to spec out and
>     >     >>> implement things, I was thinking of an indiegogo or kickstarter
>     >     >>> approach to fund the work.
>     >     >>>
>     >     >>> Chris
>     >     >>
>     >     >>
>     >     >> This has been discussed numerous times, both for eeschema and for pcbnew.
>     >     >>
>     >     >> In fact I mentioned it for pcbnew about 4 days ago again.
>     >     >>
>     >     >> The eeschema conversation is longer, and archives have it already.
>     >     >>
>     >     >
>     >     > I've done a couple of searches like "kicad online library" and "kicad
>     >     > network library" that didn't turn up anything. Were different terms
>     >     > used in the discussion?
>     >
>     >
>     >     SWEET
>     >
>     >     This design is one I wrote as a result of endless emails and thinking about it:
>     >
>     >     http://dev.kicad-pcb.org/sweet/
>     >
>     >     In the source tree you find the doxygen source to this design document named
>     new/design.h
>     >
>     >     SWEET is different than PRETTY in that SWEET is designed to be human writable, human
>     >     readable.  Whereas PRETTY was intended only to be human readable.
>     >
>     >     In the end, I decided that eeschema needed to be rewritten, not adapted.  This
>     is where
>     >     you start in a new directory and start over, but are free to copy pieces from
>     the original
>     >     work with scrutiny and refinement as you go.
>     >
>     >     It ended up being too much work for me to fund.  Get about $100,000 and I might be
>     >     interested in doing the work.  Some of it is done already however, the parser and I
>     >     started writing a GAL client before GAL was a good as it is now.
>     >
>     >
>     >     Dick
>     >
>     >
>     >
>     > Hi Dick.
>     >
>     > I went through the documents and it looks like an interesting approach to versioning
>     > parts. Clearly you've spent a lot of time building that up. I'm wondering if we should
>     > consider using a simpler, full part, versioning for the first round of any client/server
>     > api. It might not be as efficient but it would likely simplify the implementation
>     and make
>     > it easier to move parts around.
>     >
>     > Chris
> 
> 
>     KiCad treats footprints and schematic parts differently.  (Yet does not prevent you from
>     adding references from one to another.)  So if you want "to simplify", you should have one
>     conversation about each realms, footprints and schematic parts.  Two separate
>     conversations.  One in my mind is a $100,000 undertaking, the other is a mere 3 weeks
>     of work.
> 
>     Simple is the latter.  You started by saying the remote library should work just like a
>     local library for access.  Let's say that is true for read only access.  For admin, you
>     develop your webbrowser submission and patch approval process with human intervention.
>     The 3 week effort includes only the read only access, as I measure it.
> 
>     I don't think eeschema is a foundation that should be built upon.  So I don't wish to say
>     anything more about schematic part remoting, other than I will rewrite eeschema and do
>     sweet for $100,000.  Short of that is of no interest, you'd be building on sand.
> 
>     So the conversation I can help with is the pcbnew one, and writing a "read only" http
>     footprint PLUGIN is quite easy IMO.  As I look at it now, there are really 3 separate
>     conversations.  One I don't want to have again, until there is money, a second one on read
>     only access of footprints, and a third one I don't care about which is the "web admin" of
>     the read only footprint access.  You could do the latter using github pull requests.  Keep
>     it easy.  There is no versioning in the footprint PLUGIN api.
> 
>     Hopefully you can best utilize my time based on what I've said here.
> 
>     Dick
> 
> 
> On the topic of footprints vs. parts (is that the correct way to refer to them? I was
> using footprints and symbols), is there any reason why they couldn't ultimately be treated
> more similarly in terms of a client/server approach, or a file based approach? I presume
> you mean that today eeschema and pcbnew treat them differently but don't necessarily have to?

Yes, they are treated differently.  Within eeschema components are instantiations of
parts.  Within pcbnew footprints are copies of footprints from footprint libraries, aka
module libraries.  Copies and instantiations are two different things.  That's why
versioning is important for the instantiations.  That's why I put a parts list into the
new eeschema design.

Components are memory links with minor tweaks to a part.

Footprints are copies.  They don't have in memory links to any templating mechanism such
as a part.  The bottom line is this, if you want to keep it simple, then keep it simple.

These were your words.  You keep it simple by providing what pcbnew needs.

An analogy might help here.  If you go to the library and check out a bunch of DVDs, bring
them home and find that your CD player cannot handle them, you cannot simultaneously "keep
it simple" if your plan is to redesign your CD player to handle DVDs.

As it turns out, in the case of pcbnew, it is very easy to get your remote access as a
readonly facility, because the infrastructure is now there, short of one plugin.

I support "keep it simple" BTW wrt pcbnew.


Dick



> 
> Chris
> 
>