X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-transfer-encoding;
	bh=i4CCUsOJksu/SxfIOte8xCZTbz8sdtU9HeWUHClqtow=;
	b=REYJ2VvwKkx1RRWDE0vT2n+o7B2ZtddpFJLPIl7ND6IfuYImNqfMwUMlhwnRjeQNGh
	g5sZrpxYME2Pf+gQsWFp7vFjec3WWhsnbgZOQT3PRIyBA2rk3f/S8uYlYwfXO1ER+cJT
	nemggMbNwRfMRG/QJ+B1ZGN7cwXfynASB2udOg5Sr2bGxXGpEwEhrU9FKHhL1aZBqzbw
	lu6FznfICh0KsJv/Z+vEQ6fJRtXIPGMMQwoo6h7DjLfQD8gYYf5dcYdeYwMNSyWoTV3k
	CR6okm0koK94cjqJdBWANXpDS9KxzdPS7vs5aIy50qkEbQF4OkmqjU0xn0YoIAfg4hPL
	ldBw==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to
	:references:mime-version:content-transfer-encoding;
	bh=i4CCUsOJksu/SxfIOte8xCZTbz8sdtU9HeWUHClqtow=;
	b=uhmhdRWd5QkSXI6xeF5PjVKBOV9sYqyY4QaBpgZJ7FJs9t8R61RHWuXdSDn3FJ13b3
	oiCvuZMq78KGbDpOCN1iNLiWelM7EOhTg7+4qieQ3T9qJ70y3oZeVkZx/vnMuHiDBx77
	x/CV3XVkqkvDyBGdHaAvGKwNznbqcv4OeRS/bQFiIGdqabyUT2Tn1brfbYgGguOKIpR9
	TdibJ0XhQ/DSTHL1+tH1puU2NBRTyL/90DgNu6O1iuZZc7FJFFs0wMPhlOOMndQJUFHO
	SA/0lvtAohZY+0o0gWjZqVvgn6L0g4ayJO63SbAJ3fc9Mx64mJJ3c3tiN2Bk4XcBqGo3
	M64A==
X-Gm-Message-State:	APjAAAWoqh3IjDQJv9CzADQPwQsbN40WFFZu0ZV8U1v8eh7HQ3rDT6mr
	BdSSxEsonPL0dH+82166OHIob0nf
X-Google-Smtp-Source:	APXvYqy3gEuerlZ6LZzPR8ph7xL/MeWVrKf083Lr7n6nV3je0IdDyRlHUE/SAkS9w6GAVZ6xcmOp5w==
X-Received:	by 2002:a2e:884f:: with SMTP id z15mr17297124ljj.46.1582146030865;
	Wed, 19 Feb 2020 13:00:30 -0800 (PST)
Date:	Wed, 19 Feb 2020 22:00:29 +0100
From:	"N (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Proposal: Library handling
Message-Id:	<20200219220029.125afb8941f9ea3303eb9f93@gmail.com>
In-Reply-To:	<EAAB243D-EC30-44B6-99D9-377FD4A97BA9@noqsi.com>
References:	<alpine DOT DEB DOT 2 DOT 20 DOT 2002181340190 DOT 1436 AT nimbus>
	<EAAB243D-EC30-44B6-99D9-377FD4A97BA9 AT noqsi DOT com>
X-Mailer:	Sylpheed 3.7.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
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

> The thing that this proposal doesn’t address is that neither external library symbols nor embedded symbols are ideal for an evolving project.
> 
> External library symbols are good starting points, but need customization (mostly attribute additions and changes, but sometimes more) to be usable.
> 
> Embedded symbols are inflexible.

If reference is available they could be updated then neeeded.

> What works for me is to copy a library symbol, give it a name like “bypass_cap” or “low_speed_opamp” that reflects its role in the project, and place it in the project’s symbol directory. Then, instead of adding attributes to each instance, I put them in the symbol file. This makes it easy to control BOM complexity: if I want to change my bypass caps from 0603 to 0805, I do it in one place. I isolates the project from library changes without the inflexibility of embedded symbols. It solves the “light vs. heavy” symbol dilemma: you don’t need a library containing a billion heavy symbols, but your project reaps the benefits of the heavy symbols it needs.

Then you could have a local project specific library of symbols.

Have seen an example a few weeks ago there someone added an attribute to reference part and it might solve the light/heavy symbol problem. It would be possible to add feature with a list of value for attribute values referencing part is filtered depending on attribute values.

- Raw text -