X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 1 Sep 2015 04:11:13 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] back annotation proposal (RFC) In-Reply-To: <55E4BDB7.1080506@ecosensory.com> Message-ID: References: <201508301802 DOT t7UI2twS031311 AT envy DOT delorie DOT com> <201508310341 DOT t7V3fcfh022966 AT envy DOT delorie DOT com> <20150831111604 DOT 5b1bb421bc015de9a848e8a9 AT gmail DOT com> <55E42456 DOT 5080309 AT jump-ing DOT de> <20150831112032 DOT GA8963 AT visitor2 DOT iram DOT es> <20150831134127 DOT 9dccc4c2563ce7bba5ded79d AT gmail DOT com> <55E46E18 DOT 7060102 AT ecosensory DOT com> <20150831220701 DOT 929d36b81e49e264f37e61a5 AT gmail DOT com> <55E4BDB7 DOT 1080506 AT ecosensory DOT com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 31 Aug 2015, John Griessen wrote: > On 08/31/2015 03:07 PM, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote: >> it is possible changes are traveling in both directions in sort of at the >> same time if both files have been changed since the last annotation. > > Sounds too complicated for realistic volunteer coding to help. I don't need this problem be solved by a volunteer. I see this thread got derailed real fast into people speculating about things that most likely won't happen instead of trying to join things that will certainly happen one way or another. Assuming I go for the back annotation design that actually solves my problems and can be finished in a realistic time frame, what I need are probably three things: 1. minor UI changes, most probably in the C part of the gschem code. somehow ending up in the official repo; I'd prefer to avoid maintaining a fork of gschem (no, having the fork in git doesn't help). 2. a scheme script that can be plugged into gschem and do real simple things like toggling flags for point 1, counting how many flags are toggled, warn the user about the counter is being non-zero; this script doesn't need to get into the official repo 3. depending on whether we (me and my actual contributor who contributes code) go for push or pull, we need: a new action or menu or whatever that can trigger a pull or some means that can collect a change list pushed and then indicate that something's happened. It's not really a third piece of code, just a third piece of concept that is spread accross 1 and 2. First, I seek a contributor for exactly these 3 things. Alternatively if there's someone who is really willing to contribute actual code and spend time on this, I'm open to change parts of my plan if he has better ideas as long as the new approach still solves the actual problems I have. In no way I am willing to go into chasing a theoretically perfect solution that never gets implemented. Regards, Igor2