> In the lesstif HID, in lesstif_set_layer(), there is code that first
> maps an incoming group number (ie, an argument in [0..max_layer)) to
> its [0] member.  Then, if the result, idx, is in [0..max_layer+2), it
> uses PCB->Data->Layer[idx].On as the return value.
> 
> This seems to imply that (a) max_layer or max_layer+1 can be the [0]
> element of a group (rather than being a later member, just there to tag
> the group as being the solder or component side copper), and (b)
> PCB->Data->Layer[] has something useful in the [max_layer] and
> [max_layer+1] entries.  However, it is not at all clear whether that's
> actually so.

lesstif_set_layer() is passed a group number, [0,max_layer)

We map it to a drawing layer only to determine if the group is "on" or
"off".  This assumes that the core has already determined if the group
has some layers in it or not.  We shouldn't get called for empty
groups.


> Of the other places in the lesstif HID that use ->Layer[]...
> - lgbutton_expose special-cases max_layer and max_layer+1.

Because here we're using them to indicate the "solder" and "component"
side tags.  This is the "c" and "s" in the Groups() string in the file
format.

> - lesstif_update_layer_groups likewise.

Likewise.

> - SwapSides accesses those ->Layer[] values iff they are in the solder
>    or component group's [0] elements.

Only to tell if the group is being displayed or not.  The core keeps
all the "On" flags in sync within a layer group.

> All this makes it seem likely to me that PCB->Data->Layer[] has data
> for [0..max_layer), with the code that uses other entries being buggy
> (and getting away with it only by chance), with SwapSides living
> dangerously by assuming that the layer groups are "well-formed".  Am I
> right?  And, if not, what _is_ in PCB->Data->Layer[max_layer] and
> [max_layer+1]?

The two extra Layer[]s are both silk layers.  They aren't accounted
for in the layer groups table.


_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev

Reply via email to