>>> The two extra Layer[]s are both silk layers. >> So there *is* stuff in PCB->Data->Layers[max_layer] and >> [max_layer+1]? Are they full-fleged layers [...]? > They should be full layers. The name might not be useful though.
I assume they can appear in LayerStack[0], ie, be the current layer? (Since I suspect there's no other way to get stuff into them....) What about .On? The lesstif HID uses PCB->ElementOn and SL_MYSIDE() when set_layer is called for an SL_SILK layer, and I'm not seeing set_layer calls for the silk layers under their max_layer and max_layer+1 identities (though there is no interface spec that defines whether this is by design or by accident of the implementation, as far as I can see). Is there any use in looking at or changing the .On flags for the extra layers? Well, except for keeping all the members of a group set identically (vide infra)? Actually...upthread, you wrote > The core keeps all the "On" flags in sync within a layer group. Where is this done? As far as I can tell, the lesstif HID, at least, bashes the .On flags directly, rather than giving the core a chance to get its fingers in the pie. It does take care to change all the .On flags for a group together, but it seems to run counter to your saying the core is responsible for keeping them in sync. (Even if the core wants to, it's not clear when it has a chance; I don't see any call from the HID into the core corresponding to visibility changes.) What breaks if different layers in a group have different .On values? Based on the (relatively small) amount of code I've read, all this will do is render some code schizoid about whether layers other than the group leader (the one in slot [0]) are visible. This is hardly good, but it's probably not catastrophic; is there anything worse? This whole mess is crying out for a redesign...but I rather suspect that by the time I have my head around it enough to do that, I'll be in much the same position you are, and find it less pain to just hold my nose at the mess than to actually do changes sufficiently intrusive to deal with it properly. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
