[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