| delorie.com/archives/browse.cgi | search |
On Tue, Sep 8, 2015 at 12:33 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>> 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
That's quite a variety of sources. In the past I've wondered if Make would
be a good tool for dealing with these two facts:
1. Expect user clone-and-modify is more useful strategy than trying to have
exhaustive libraries
2. There are lots of ways of making symbols/footprints out there already
For us to effectively share symbols (parts in my case -- I use all
heavy symbols)
with each other, we need a common interface that specifies how they are
created, so we can easily understand the code at need and external tools
can access them. Make is the closest we have to a lingua-franca for
that purpose.
I'm thinking of the way Debian works, where standard, well-described targets are
expected to do particular things in the construction of packages. The debian
approach has worked nicely both for rendering diverse build systems
more easily comprehensible and for allowing automation over the packages.
How does this seem to others, reasonable or weird?
Britton
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |