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:	<alpine.DEB.2.00.1509010353280.6924@igor2priv>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1508301838470 DOT 6924 AT igor2priv> <201508301802 DOT t7UI2twS031311 AT envy DOT delorie DOT com> <CAM2RGhRgPQG2WDFVb0SFvMbypyYKS2oYtD=851WHR6fOB4iWdA AT mail DOT gmail 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> <alpine DOT DEB DOT 2 DOT 00 DOT 1508311725150 DOT 6924 AT igor2priv> <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
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

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

- Raw text -