X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Fri, 11 Sep 2015 16:38:03 -0400
Message-Id: <201509112038.t8BKc3GP013110@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <20150911222120.e57a7e4dca6baabdbdf6287c@gmail.com>
	(geda-user AT delorie DOT com)
Subject: Re: [geda-user] About reinventing the wheel, and how to avoid it
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1509111150410 DOT 2482 AT lichen>
	<B94E2C24-8B63-46FC-A551-9E4B14B817C9 AT noqsi DOT com>
	<201509111624 DOT t8BGOPYV000685 AT envy DOT delorie DOT com>
	<20150911190224 DOT 5b50175919e00b91df2ccf53 AT gmail DOT com>
	<201509111707 DOT t8BH7kS8004233 AT envy DOT delorie DOT com> <20150911222120 DOT e57a7e4dca6baabdbdf6287c AT gmail DOT com>
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


> Even though you have to remember attributes and values yourself it
> is not just arbitrary text. For already defined attributes it would
> have been nice with a list to choose from and for each attribute a
> list of predefined values to chose from where appropriate.

It's not "just arbitrary" because some other tool (typically gnetlist
for gschem) interprets the values.  But as far as gschem itself is
concerned, aside from a few convenience pulldowns that provide
commonly used defaults, the text really is just arbitrary.

If you were using gschem with something other than gnetlist, which had
a different interpretation of the text, it would still not be "just
arbitrary" to that other something, but not because gschem itself gave
it any meaning.

Thus, my position that adding arbitrary text *in gschem* is not
difficult.

The task is more difficult in something like pcb because the
attributes have meaning *to pcb*, and pcb usually has to interpret
them in realtime as the user is editing.  It's the meaning that causes
the difficulty, not the attribute storage itself.  The realitime
requirement often dictates a non-"arbitrary" internal storage as well.

(this is similar to the XML "problem" - XML defines a structure for
storing information, but doesn't give any meaning to the information,
leading to lots of incompatible implementations)