X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sun, 1 Sep 2013 16:37:14 +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] PCB file format - compatibility suggestion
Message-ID: <alpine.DEB.2.00.1309011636420.11551@igor2priv>
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

On Sun, 1 Sep 2013, Markus Hitter wrote:

> I find all three of them very useful! For example, this intconn thing.
> So far the only solution I could find was to add a layer just for this
> internal connection.

I am happy to hear that.

> 
> 
>> The only patch I could extract is from my svn; if anyone wants to invest
>> the time to merge it with current versions (but I based my branch on the
>> last stable release, which is like 2 years old), attached. It doesn't
>> add an UI for editing those unknown flags. Since this patch was for my
>> fork, I did not follow the (inconsistent) whitespace and naming
>> conventions of the existing code.
> 
> I searched versions back to 2006 to find a version where globals.h fits,
> but couldn't find one. As I don't really understand what the code in the
> patch does, it'd be a bit of gambling to force it in regardless.

I've started mine from the debian patched version of release 20110918; it was 
the first code commited to the repo, so getting diffs based on this should be 
easy.

> How about putting your whole work into the central repo?

I am not against it, as long as it doesn't cost me any time. In other words: my 
work is in a public svn repo (with micro commits, tagged commit messages, etc); 
if a volunteer may be willing to copy and merge my changes to the central repo, 
it could work.

> Questions to the audience:
> 
> - Do the above three approaches look good? Better ideas on how to
> implement the functionality (i.e. without a pin flag)?
> 
> - With all three examples implemented, is it still a good idea to allow
> arbitrary flags?

Yes. I am working on more features, and some of them may need new flags. I 
think it's generally a good idea to make PCB keep anything it does not 
understand, especially if it's as easy as with these flags. I see no reason why 
it should delete them.

Regards,

Tibor