DJ Delorie wrote:
>> We have footprint attribs now,
>> and this seems like one of their reasons-to-be.
>
> Attrib("paste:p14" "grid,5,4,50%,470pL")
>
> Means: paste for pad p14 is a 5x4 grid, 50% coverage, total of 470pL ?
> I suppose glue:p14 and other attributes would work too.
Sure thing. Only the dimensioning concept of never putting
conflicting dims on a drawing is partly crossed by saying pL, a volume. Could
be good to say
a planned depth of paste that goes with this pattern since it is closer to a
variable you can control. From which volumes would be derived.
>
>> This kind of function will involve somehow choosing as you go
>> whether the draw_everything routine in draw.c handles a pcb object,
>> or if a plugin is doing it. Wouldn't it be nice if plugins did all
>> the drawing? And if the code of pcb that chooses what routine draws
>> what object was clear and compact?
>
> Hmmm... drawing hooks. "I know how to draw XYZ" could match up with
> Attrib("plugin:foo:..." "...")
>
> I suspect designing an API to handle different plugins handling
> different aspects of each footprint, and priorities, would be tricky.
Yep. Tricky. I'm going to outline some of pcb and see what ideas I can
generate though.
John Griessen
--
Ecosensory Austin TX
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
