| www.delorie.com/archives/browse.cgi | search |
--089e01536d30c740d7051f417940 Content-Type: text/plain; charset=UTF-8 On 8 September 2015 at 20:53, DJ Delorie <dj AT delorie DOT com> wrote: > > > > For me it seems like a problem to never be allowed to change an old > symbol without breaking schematics using them. > > > > Or to be able to remove old rusting symbols from the distributed library. > > Perhaps we're finally seeing the dark side of a toolkit approach - the > toolkit leaves too much of the management to the user? What will really happen the day somebody removes the obsolete symbols? Users will have to change to an old tag in their git clone and get those symbols into their own symbol cache. > > And then, ngspice users want an ngspice-oriented library, pcb users > > want a pcb-oriented library, VHDL users want a VHDL-oriented > > library, etc. It seems to me that a project library management tool > > would be very useful. > > Yet another task that would fit into a proposed component database > manager? Or is this something that the other tools need to know > about? > > In kicad there seems to be a component cache stored locally in case the original library falls out of the library search path. That would be a feature gschem would need to know about. If a symbol is placed in the schematic, it is also placed in the local cache. If it is deleted, maybe it should be deleted from the local cache to prevent filling up the disk. -- Svenn --089e01536d30c740d7051f417940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= September 2015 at 20:53, DJ Delorie <span dir=3D"ltr"><<a href=3D"mailt= o:dj AT delorie DOT com" target=3D"_blank">dj AT delorie DOT com</a>></span> wrote:<br= ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex"><span class=3D""><br> > > For me it seems like a problem to never be allowed to change an o= ld symbol without breaking schematics using them.<br> ><br> > Or to be able to remove old rusting symbols from the distributed libra= ry.<br> <br> </span>Perhaps we're finally seeing the dark side of a toolkit approach= - the<br> toolkit leaves too much of the management to the user?</blockquote><div><br= ></div><div>What will really happen the day somebody removes the obsolete s= ymbols? Users will have to change to an old tag in their git clone and get = those symbols into their own symbol cache.</div><div><br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex">=C2=A0<br></blockquote><blockquote class=3D"gmail_quote"= style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><s= pan class=3D""> > And then, ngspice users want an ngspice-oriented library, pcb users<br= > > want a pcb-oriented library, VHDL users want a VHDL-oriented<br> > library, etc. It seems to me that a project library management tool<br= > > would be very useful.<br> <br> </span>Yet another task that would fit into a proposed component database<b= r> manager?=C2=A0 Or is this something that the other tools need to know<br> about?<br> <br> </blockquote></div><br></div><div class=3D"gmail_extra">In kicad there seem= s to be a component cache stored locally in case the original library falls= out of the library search path. That would be a feature gschem would need = to know about. If a symbol is placed in the schematic, it is also placed in= the local cache. If it is deleted, maybe it should be deleted from the loc= al cache to prevent filling up the disk.</div><div><br></div>-- <br><div cl= ass=3D"gmail_signature">Svenn</div></div> --089e01536d30c740d7051f417940--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |