gEDA-user: Thindraw and the HID interface... [WAS: Re: pcb segmentation fault]

[Peter Clifton <pcjc2@xxxxxxxxx>]

I've committed Levente's patch for the PNG hid, and a slightly modified
version of Ineiev's for the gerber HID.

grep revealed no other cases jumping out to worry about (at least none
testing the width for == 1 or any other inequality).

I do wonder if nelma might be doing the "wrong" thing by not ignoring
thin-draw lines around things like holes though.

(Its brush creation code is slightly different to the png HID, so it
doesn't look like it should crash - although I've not tested that
explicitly).


On Fri, 2009-03-06 at 12:30 -0500, DJ Delorie wrote:
> Two thoughts:

Both good ideas:

> In the case of holes, I'd mentioned before that we should add a "draw
> pin" hook that passes the whole Pin structure, rather than
> interpreting it, for HIDs that want more control over how pins/vias
> are drawn (example: gerber wants to flash them, not draw them).  That
> would bypass this problem as the gerber hid could do the right thing
> on its own.

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. I suspect
we need a more savoury way to allow the HIDs to include the PCB
data-types. I wasn't particularly happy with moving the typedef of the
PolygonType arbitrarily.

It might just be my unfamiliarity, but PCB does seem to lack a coherent
policy on what header files get included from where. (The #ifndef guards
seem like they must get used a bit!). I don't expect my changes to
introduce the "fill_pcb_polygon" hook made things any better (sorry!).

> We could add a "supports thin-draw" flag to the HID flags definition.
> Then we could move the thin-draw overrides out of the hid and into the
> core (currently, some hids temporarly disable thindraw when they have
> control).  OTOH, I'd like to occasionally print a thin-drawn board to
> paper, too.

I guess the HID could toggle its acceptance of that flag at run-time.
(As an override to force thin-draw off if the user requests it). In
other cases, the current user setting for thin-draw would just be used.

Btw.. I like the idea of having finer grained control over thin-draw. It
was handy for polygons separately already, and I've found that a
combination of outline drawing and transparent fill is quite productive
(if slower than a plain fill).

KiCad actually lets you control thindraw (sketch mode) separately for
lines, pads and polygons. Their thin-draw lines are not quite like our
centre lines.. they are a full outlines with arc caps, which looks quite
appealing. The possibility of both is nice.

For the GL stuff, eventually we might like the following:

Drawing "modes" / options per object type. Perhaps we provide some
pre-defined default styles. Each should be adjustable:

Outline hair draw     (on / off, colour, opacity)
Solid fill            (on / off, colour, opacity)
Centreline hair draw  (on / off, colour, opacity)
Object manipulatable? (on / off)

If you could think of the use-case / desired visual effect, you could
also fiddle with the compositing modes (perhaps XOR, for example), and
perhaps adjust the way masking / sub-compositing works (both of which
might require defining / configuring, their draw-order).

This brings hiding / showing certain objects to a special case of
adjusting their drawing style. Presumably we'd still modulate object
manipulability when toggling to invisible drawing styles, or perhaps
certain thin-draw modes. (E.g. how we treat thin-draw polygons).


Somewhat on this topic..

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. Pads are surface layers only,
and when editing a middle layer of a multi-layer board, you might often
want to switch of pads, but _not_ pins.

I'm minded to re-group the visibilities as "Pin/Via" and "Pads".
Alternatively we could make all three separate, but it does mean more
vertical space used in the layer stack list.

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.



Best regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user