X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=mail.ud03.udmedia.de; h=
	message-id:date:from:mime-version:to:cc:subject:references
	:in-reply-to:content-type:content-transfer-encoding; s=beta; bh=
	hP+BaG0k84pUydGtAJxTdvMBzqwkCAHoj+QPbjDGbwA=; b=fodjcYJtyipTQlte
	e7XPT+x2e5q9RpU33NMPbSlNuXksSwNu2GzqQ8EYIVnE/s1+6p8cRc/dyha1v6oK
	9RetOZv/i5KjH+EpoH/L5R5rds26d5jltN6zGZUZHtolcm8FmSNC0rFBvv5oJkeU
	r6LMtizsJgAQiDohZI1PdJYzTsM=
Message-ID: <52234C02.5090508@jump-ing.de>
Date: Sun, 01 Sep 2013 16:15:30 +0200
From: Markus Hitter <mah AT jump-ing DOT de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: geda-user AT delorie DOT com
CC: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] PCB file format - compatibility suggestion
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1309010843540 DOT 11551 AT igor2priv> <5223378D DOT 4010208 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 00 DOT 1309011501520 DOT 11551 AT igor2priv>
In-Reply-To: <alpine.DEB.2.00.1309011501520.11551@igor2priv>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

Am 01.09.2013 15:13, schrieb gedau AT igor2 DOT repo DOT hu:
> In my version:
>  - nonetlist flag of an element means the element is not in the netlist
> and should not cause a short (useful for 1206 jumpers - I hated to add
> them on schematics)
>  - intconn(g) for pins and pads, representing internal connections of an
> element, which my version of find.c can track (g being an integer group ID)
>  - shape(i) for pins to have more polygon shaped pins beyond square and
> octagon

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.


> 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.

How about putting your whole work into the central repo?

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?


Markus

-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/