X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Authority-Analysis: v=2.0 cv=V4T/IJbi c=1 sm=0 a=EjztJWFdnv6i9TIhvw6sWw==:17 a=21ICLxYkRVwA:10 a=rDn-WTkdBtsA:10 a=cLgIy9FZ2aIA:10 a=6WB07kdHjWAA:10 a=8nJEP1OIZ-IA:10 a=wR-FlJDvAAAA:8 a=KGjhK52YXX0A:10 a=gfI11CQHqfoA:10 a=C05BmDLEZeoZ3EwlGcYA:9 a=wPNLvfGTeEIA:10 a=EjztJWFdnv6i9TIhvw6sWw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 72.179.44.248 Message-ID: <522E59CF.7070502@ecosensory.com> Date: Mon, 09 Sep 2013 18:29:19 -0500 From: John Griessen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] [RFC] Major changes to symbol/schematic libraries in geda-gaf References: <87ob83dodl DOT fsf AT harrington DOT peter-b DOT co DOT uk> <201309082106 DOT r88L6uGB008410 AT envy DOT delorie DOT com> <87ppsjas54 DOT fsf AT harrington DOT peter-b DOT co DOT uk> In-Reply-To: <87ppsjas54.fsf@harrington.peter-b.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com On 09/08/2013 05:02 PM, Peter TB Brett wrote: >> cloud support, >> >likehttp:// and git:// paths. > It would be cool, but I feel like that might be better implemented via > helper daemons that just keep an on-disk library up-to-date. You > wouldn't need any synchronisation with gschem; the library system would > monitor the filesystem and DTRT when updates occurred (i.e. prompt the > user, probably). Sure. The daemon could trigger reminder emails as updates pile up. The data could get too large to function well. The code would be simpler than integrating http:// data translation with gschem. Some tool to search through data that is in usable form would be needed before being able to list it in a remote library. On 09/09/2013 03:39 AM, Gabriel Paubert wrote:> On Mon, Sep 09, 2013 at 11:31:29AM +0400, Vladimir Zhbanov wrote: . . >> I'd even prefer to somehow force gschem make local copies of >> new symbols every time I add them in a schematic, and further >> work with these copies (it also would make any project >> independent of any library changes). > > That would be my preferred way too. In this case, the whole project > becomes completely independent of what is in the libraries when > you update the system. Or when you switch machines That's my method also. On 09/09/2013 04:11 AM, gedau AT igor2 DOT repo DOT hu wrote:> I agree. I run into this problem from time to time that the schematics I wanted to use on another computer or share depends on a > symbol in a library that I forgot to commit or fetch. > > On the other hand I do understand the opposite use case, when someone fixes a problem in his library and wants the fix to take > effect on all schematics, immediately. So coming up with a configuration way to choose these functions would be a help. Then distributing gschem with these ways as setup choices with them handled easily would help get new users. The start up hassles still put off people from using gEDA tools even though they want to openly collaborate with FOSS tools to build OSHW.