X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Tue, 8 Sep 2015 16:33:54 -0400
Message-Id: <201509082033.t88KXsFZ005209@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <307FD655-69A7-4486-B466-B5FB92CBB1C2@noqsi.com> (message from
	John Doty on Tue, 8 Sep 2015 13:52:20 -0600)
Subject: Re: [geda-user] Desired changes (was:"New experimental netlist features")
References: <alpine DOT DEB DOT 2 DOT 11 DOT 1509031356150 DOT 13201 AT nimbus> <55E8773B DOT 9000902 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509031846370 DOT 7163 AT nimbus> <55E8831A DOT 8050307 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509032004020 DOT 10628 AT nimbus> <55E891FA DOT 2010509 AT jump-ing DOT de> <alpine DOT DEB DOT 2 DOT 11 DOT 1509032039300 DOT 14871 AT nimbus> <BC7E3E69-4914-4654-B020-1338C71E0CDB AT noqsi DOT com> <201509032030 DOT t83KU1Yq017045 AT envy DOT delorie DOT com> <55E97A3E DOT 2070402 AT jump-ing DOT de> <69B8B3F4-A6E4-43E9-9055-C63A5D6A3707 AT noqsi DOT com> <msfjma$340$1 AT ger DOT gmane DOT org> <alpine DOT DEB DOT 2 DOT 00 DOT 1509060518220 DOT 6924 AT igor2priv> <msidqe$66h$1 AT ger DOT gmane DOT org> <D2219618-B906-432B-B11A-C108DA9FCBF9 AT noqsi DOT com> <CAOP4iL3JkWC4Nuw8vDOBDR4Zk4OD2xwrMwHXp-ZihPom5Wmfwg AT mail DOT gmail DOT com> <43CA04C5-47B7-4DA4-8005-3A2D4E9D0E47 AT noqsi DOT com> <20150908162514 DOT 43142577ec15e48c50950a18 AT gmail DOT com> <CD93E147-F22E-4CA2-9793-FAAA5558486D AT noqsi DOT com> <20150908182504 DOT 196a11571c68bc63ef8e4c27 AT gmail DOT com> <11875D68-7D82-48AB-8850-C5C3BCCF64EC AT noqsi DOT com> <201509081853 DOT t88IrAak001304 AT envy DOT delorie DOT com> <307FD655-69A7-4486-B466-B5FB92CBB1C2 AT noqsi 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


> It's the cost of being able to do things that the developers never
> imagined.

Yeah, I'm just saying we're seeing that cost now.

> There's a role for integrated tools.

This is not an argument for integrated tools, just an argument that
using a toolkit so you don't have to anticipate user's needs means you
might end up not building a robust enough toolkit.  We took a shortcut
in gschem because it met one person's needs, and it's causing problems
now.  We need to be willing to tweak the toolkit model if needed, if
we see that it's not as usable as it could be.  Even things like the C
and C++ standard libraries go through this process, painful as it
might be, when appropriate.

We currently say "this directory is our library".  Maybe as part of
the component database project we need a new thing that lets us say
"this tool provides our library" ?  If it defaults to "this directory
is our library" then it's backwards compatible, too.  The "this tool"
can be a linked-in library, runtime plugin, external tool, or net
connection, depending on how we choose to implement it.

The only real integration into the GUI tools is if the user says "I
need a NAND gate" that tool might need to ask them to clarify in order
to provide a unique-enough object (how many inputs?  do you need
schottky?  what speed family (if it matters)?  Is this a default gate
(heavy sym) or specialty (light sym)?  What package do you want?  What
speed class or voltage family?  Is an ideal model OK?).  In gschem for
example, the tool might generate the symbol heirarchy on the fly based
on what alternatives are available, so instead of:

symbols
 -> 74 series
   -> 7400-1.sym
   -> 7400-2.sym
   -> 7400-3.sym

You might see

symbols
 -> logic gates
   -> NAND
     -> by-inputs
       -> 2-in
       -> 3-in
       -> 4-in
     -> schottky
 -> 74 series
 -> vetted
 -> in-use

(I can't think of a good way to turn digikey's search forms into a
menu bar option :)

(and maybe a menu bar option or gtk-tree isn't the best way to display
a library, either)

(in my blue-sky, the interface between apps and the CDM was a remote
query, where you send "what you have" and it sends back what
alternatives remain, or sends you the component info you selected)

> It's a little different. I see the component database manager as an
> automated editing/annotation tool between schematic capture and the
> downstream simulation/layout/documentation flow. But up front, you
> may want a tool to select the subset of symbols to use for the
> project in the first place.

I figured the component database manager (CDM) would need to have some
configuration that said where to get components from (project-specific
files, installed libraries, web servers, sql, whatever) and part of
the selection criteria could include project-specific tags (like "for
simulation"), corporate vetting info ("approved for release"),
timestamps, versioning info, whatever.  The CDM could be configured to
generate a cache of parts, and include that cache in its search path.

So if you're doing a board layout with standard specs, you'd include
your "personal defaults for standard pcbs" library second in the
search path, right after "project-specific parts cache".  Then add
"corporate library where target == layout" etc.

If you wanted to do an update, you'd ask the CSB to search for
alternates further in the library list, compare, and possibly update
(or just invalidate) the cache.

The reason for integrating it is because the configuration of the
CDM's search path and rules *is* how you select subsets.

Heck, you could have a target field in each part that lets you say "select
only type == pcb" or "select type == sim.gnucap then type == sim"

So all the special cases you're asking for are just fields you select
on when you do your queries.  It's highly flexible, and we don't have
to guess the fields in advance.

(of course, all this is in addition to whatever mechanism the CDM has
to interact with the user to resolve conflicts and choose alternatives
- but how is "resolving conflicts" really different than "updating
components" or "choosing defaults" ?)