Mail Archives: geda-user/2015/09/09/09:50:15
On Sep 8, 2015, at 2: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.
Well, I’ve seen that cost for 13 years. It’s been worth it.
>
>> 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.
What do you mean?
> 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.
The high road to tweaking a toolkit is often to add new tools.
> 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.
Perhaps, although the advantage of using directories as packages is that they are transparent and accessible to other tools and even simple shell commands.
>
> 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)
Are you proposing putting this knowledge in the tool? That could cause problems. Digi-key has the best catalog interface of this type, but it’s the “Girl with the Curl”: “When she was good she was very, very good, but when she was bad she was horrid.” It channels the user into the categories marketers understand, but often I need a part selected by physical criteria not captured by the database. It can be easy when the scenario matches, but it can be frustrating when you’re doing something out of the ordinary.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -