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