X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
From:	geda AT psjt DOT org (Stephan =?utf-8?Q?B=C3=B6ttcher?=)
To:	<geda-user AT delorie DOT com>
Subject:	Re: [geda-user] The nature of gEDA users
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1601260416150 DOT 9035 AT igor2priv>
	<56A751EC DOT 8030402 AT iae DOT nl>
	<20160126124701 DOT 0d061912c7e078ced9d4e6cb AT gmail DOT com>
	<CANEvwqgs3YFnt7m8mA1DN6X2KdWbyr4zpXCVH321vDo1f7CyxA AT mail DOT gmail DOT com>
	<201601261804 DOT u0QI4KEQ009550 AT envy DOT delorie DOT com>
	<E7D351BF-5BBB-41AC-B996-D5E27079A82C AT noqsi DOT com>
	<CAC4O8c-ZyNnCzCDHXkYYabSD4fG8vf+CKmhMycNJujGMPKzQDQ AT mail DOT gmail DOT com>
	<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
	<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
	<CAC4O8c9RDJc17XGo-H6DuN5h76RKhQmRNGpcn3DKBKUBP=PuCg AT mail DOT gmail DOT com>
	<s6nwpqvfp2n DOT fsf AT blaulicht DOT dmz DOT brux>
	<CAC4O8c_RnsJRtDxJ-7Bqemt=m2m3ackzkrTiFPSCAhobKQveyA AT mail DOT gmail DOT com>
Date:	Wed, 27 Jan 2016 20:53:56 +0100
In-Reply-To:	<CAC4O8c_RnsJRtDxJ-7Bqemt=m2m3ackzkrTiFPSCAhobKQveyA@mail.gmail.com>
	(Britton Kerin's message of "Wed, 27 Jan 2016 08:56:10 -0900")
Message-ID:	<s6npowmdciz.fsf@blaulicht.dmz.brux>
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
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

"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
<geda-user AT delorie DOT com> writes:

>> The Via is a container with Attribute "Via".  An Element is a container
>> with Attibute "Element".  The GUI HID shall present those as special
>> types to the user, in component libraries and via stack editors. But in
>> the data structures those could well the the same as a hierachical
>> sublayout.
>
> Sounds reasonable, although also like a lot of implementation work.

The aim should be to change PCB in small incremental steps.

- Remove the assumption that all layers except "outline" are conductive.
- Make implicit layers explicit and allow to draw on them, soldermask, solderpaste.
- Allow more/all things inside Elements, on explicit layers.
- Use a mapping from Library layer names to Layout layer names.
- Allow to draw negative objects.  Add drawing depth to the objects.
- Represent the implicit objects explicitly, clearances, soldermask, solderpaste.
- Make Vias more like Elements.

First change the data structures, and update the tools do exactly what
they did before, then think about which new possibilities to present to
the GUI user, and how.

- Add a via stack editor.
- Add grouping of layout objects.

>>> That's pretty different from gschem, which uses attributes (duck
>>> types) for most things.
>>
>> I like attributes.
>>
>>> Regarding making arbitrary containers, I'm not convinced its a good
>>> idea.  Entire layouts serve much the same purpose and can easily be
>>> copied about.
>>
>> I'd like to instanciate the same sublayout by reference, so I can edit
>> the master and all copies follow.  Problem: How to override atributes
>> (refdes) on the copies?
>
> I guess if there are real use cases.  So far what happens for me is I
> use the sublayout (scripts take care of refdes changes), thenchange it
> slightly to fit in the new board, and after that no way do I want it
> to follow any subsequent changes to its parent.

Same here.  But then, I discover that I need to adjust some lines in all
30 copies, of forgot to fix the refdes positions ...

Group instances by reference may be usefull vor Elements and Vias.
Sure, it must be possible to convert such an instance to a copy, if an
individual instance needs tweeking.

-- 
Stephan

- Raw text -