[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Thindraw and the HID interface... [WAS: Re: pcb segmentation fault]
> 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
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user