[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Light? Heavy? Reuse...
On Jan 21, 2009, at 12:43 AM, DJ Delorie wrote:
>
>> It seems to me you're arguing for a plugin mechanism for gnetlist,
>> too.
>
> Perhaps, or something more global. I.e. it would be nice if you
> *could* query these extra databases from within gschem or gattrib, for
> example, to see what the inferred attributes are, or to see what the
> options are so you can explicitly set something. For example, if you
> specify a 1k resistor, it may give you a choice of 0603 or 0805
> footprints. By choosing one of those, you've helped direct gnetlist
> towards a specific part and the extra attributes that go with it.
>
> So the two types of "plug-ins" would answer these questions:
>
> 1. Given the attributes the user has already specified, what other
> attributes may be set and to what values?
>
> 2. Given a set of specified attributes, what other attributes are
> needed, and can we infer the values of those attributes, either by
> process of elimination or by project-specific defaults or rules?
>
> The second needs the first, of course, but both should be available to
> more than just gnetlist.
>
>> Right now, gnetlist merges netlists and attributes extracted
>> from gschem schematics, and then passes that information to a "back
>> end". But why not allow multiple front ends? Merge information from
>> multiple formats into the data structures. Then allow "filters" to
>> work it over: that's where one might implement a "requirement to BOM"
>> process. Finally, pass that to the back end as now.
>
> Certainly a good idea, except that it doesn't offer a way to feed-back
> to gschem for things that the user *must* (in their opinion) select.
> For example, what resistor values are available? In what tolerances?
> If you pick a 10uF capacitor at 10v, what's the smallest package it
> comes in?
That's why when I do this the next screen over is a Digikey search.
> Like I've said before, the schematic is more than topology
> - it's design. Some attributes are intrinsic to the design, like
> resistor/capacitor values, and should (according to some folks at
> least) be included with the schematic.
Yes, we should support that possibility, and we do. But we should not
cater to the desire for a tangled flow, or a toolkit that isn't
easily scriptable.
>
> The extra database contains (or could contain) all this information.
Millions of entries. Impractical for us to maintain.
> It's up to the user to specify *enough* attributes to uniquely
> identify a specific physical part (in the pcb case at least), or in
> combination with a BOM tool or preferences ruleset, at least be able
> to pick something appropriate. However, IMHO the user needs access to
> these attribute options in gschem.
Why? gschem would just pop up some window for this anyway. Why not
"stand on the shoulders of giants", use the web here?
> They may not always use gschem for
> this; there's no reason why the choices or rulesets can't go
> elsewhere, but a goodly chunk of our userspace will want a way to
> choose such things right in gschem. Especially if one of the
> attributes is "value" :-)
Yes, "value". Also other things like "footprint" when the defaults in
capacitor.sym, for example, are wrong.
>
> The key to heavification is that some of the inferred attributes
> include the pin name-to-number mapping. This lets you use really
> light symbols without the "transistor problem" we currently have. But
> even then, users may want to direct this slotting from within gschem.
And we should resist the temptation to give in here. "A program
should do one thing well". Every complex behavior added to gschem
will make it harder to manipulate the design files with other tools,
because those tools will have to satisfy the inevitable constraints
the complexity puts on the relationships among the data objects.
Right now, gschem is almost completely ignorant of what attributes
mean, and I would hope this would continue to be the case. As we have
seen with slotting, once gschem starts to model the meaning of an
attribute, all kinds of unanticipated problems arise.
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user