> I guess this could be done similarly to how I've added the hooks for > drawing (and thin-drawing) polygons by passing raw PCB data.
Yup. > I suspect we need a more savoury way to allow the HIDs to include > the PCB data-types. Nope. HIDs can include whatever core headers they want, access any core data structures, call any core functions. The core can't access HID internals - only the HID API in hid.h. > I guess the HID could toggle its acceptance of that flag at run-time. I had hoped at some point to move thin-draw to its own HID, and allow HIDs to be stacked. Then the thin-or-not choice is independent of the export/gui HID. > Btw.. I like the idea of having finer grained control over thin-draw. Agreed. > Our visibility groups allow toggling of pins / pads, and vias > separately. Since Vias are presently all-layer constructs, as are pins, > it makes more sense to group those two. Please don't. I don't mind splitting pins and pads, but I toggle pins and vias separately a lot - especially when I want to select them by type, check masks or clearances, etc. > For GL (which can do opacity quite easily), some kind of (optional) > automatic fading (or just toggling) of surface features like pads > might be useful, based on the active layer being worked on. Or do like we do with the "invisible" stuff? _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
