kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Thu, Aug 8, 2013 at 6:09 PM, Dick Hollenbeck <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>> 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>> 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?

Chris