> 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....)
Grep for PCB->SilkActive in macro.h > 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). In hid.h note the SL_* enums that are used to indicate the various layer types, silk included. > 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)? Not sure. > 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, hid/lesstif/menu.c:layer_button_callback(). > 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. Ok, maybe it's up to the HID to keep them in sync. The core certainly assumes they're in sync, although the lesstif HID at one point let you toggle them indepdendently. It didn't alway work right then ;-) > What breaks if different layers in a group have different .On values? Worst case is that only the first (in the group table) is honored. > This whole mess is crying out for a redesign... Or at least some helper functions in the core that manage it all. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
