Mail Archives: geda-user/2015/09/08/16:34:08
> 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" ?)
- Raw text -