[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: General Layers questions



DJ Delorie <dj@xxxxxxxxxxx> writes:

>> Hide all composites with attribute "type=via".  The GUI probably
>> maintains an extra list of those, as well as a list of elements, for
>> performance.
>
> Why the GUI?  Why can't the core maintain that list, since a lot of
> things will need it?  I care a lot about performance.

Sorry, yes, that's what I meant.  But it's not in the disk file.

>> Exporters can only export what they know about.  All layers can be
>> turned into gerbers.
>
> Except gerbers have special cases for thermals and pads, for example.
> If you use the special cases, other CAM tools empower their users to
> do more things (like auto-generate paste stencils when you forget the
> paste mask, which does NOT work with pcb's gerbers).  But for the
> exporters to offer these special cases, they need to know more about
> the data they're given than just "draw circle here".

So there need to be attributes on shapes.

>> At the bottom, a layout is a set of layers with attributes,
>> containing shapes, maybe with attributes.
>
> and containing other layers as sub-layouts.  I have never disagreed
> with this!

Oh.  My understanding of composites is different.  I assume a composite
contains shapes that go on a global set of layers.

> What I disagree with is using this "at the bottom" information to
> re-produce the semantic information inherent in a "pcb layout".  I see
> no reason why there can't be a semantic heierarchy to the data, so at
> a high level we have a collection of "all vias" that's a child of
> "this layout", so that the tools can find them easier and deal with
> them as a group.

Well, yes, it can, except that a via is not sufficiently special to
justify the distiction.  What would we have in a composite, the layout
being the top-level composite?

  Vias
  Elements
  Composits that are not Vias or Elements
  Lines
  Shapes outside of composits that are not Lines

How the layers fit in here depends if they are global or local to a
composit.  I did not think about non-global layers yet.

The set of global layers is the union of layers referenced in the
hierachy of composits.  When an how to map generic element layers to
layout layers is another good question.  And how to treat conflicting
attributes of layers.  I'd flag those as errors.  Or define for each
attribute lookup if the precedence goes from outside to inside, or from
inside to outside starting at some shape.

Global layers can be mapped at load time.  Local layers inside composits
must be mapped a runtime, don't they?



>> The semantics of those attributes is what encapsulates the builtin
>> knowledge how to make PCBs, and the tool must fully exploit that
>> knowledge when presenting a layout to the user.
>
> Forcing tools to "fully exploit" data at too low a level makes it very
> difficult to create such tools in the first place.  The move tool
> needs to know the difference between an element, a via, and a trace,
> so it can function properly.  We need to consider these types of
> issues when designing the internal data structures, or it will be so
> difficult to write the software that it just won't get done.



-- 
Stephan


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user