gEDA-dev: PCB HID

[DJ Delorie]

> But, what if you wanted to support multi-threaded actions.

In theory, you'd have the gui be a parameter to the function, or a
thread-local variable.  In practice, we got what we needed with a
simple global variable.  At least, the HIDs themselves don't make such
assumptions, but the core does.

> Am I missing something here is there another reason?

The HID abstraction is a compromise between what PCB needed, and what
most graphics libraries implement.  As such, it's perhaps more strict
about isolation than the pcb core needs at the moment.

> The abstraction for pcb seems to be spread out between the files
> directly in the src directory and those in the src/hid path. I suspect
> because of making the hid around a lot of existing code.

Partly.  The rule is that the core must always use the hid api, but
the hids may fiddle with the core internals if it wants.  The goal is
to be able to swap out HIDs, not to make it a perfect split.

I tried to put the HID api as close to the bare metal as I could
without the core needing to know about how the data is being presented
to the user.  The core cares about the PCB data and how it "looks" on
the board, but the HID is responsible for deciding how to turn that
"pcb look" into something for the user, be it a lesstif window, a 3-d
rendering, or a bill of materials.

> For example here in the low level line draw we expect the line to
> know if it is ment to be drawn thin or not.

Why?  A "line" is a physical object in PCB; how to represent it is not
an inherent property of the line, it's a properly of what you're doing
with it.  The code that's manipulating the line is the one that tells
the gui how to represent the object.

Perhaps in gschem it's different, because lines are abstract in
gschem.  But in PCB, what it *is* and what it *looks like* are two
different things.

> Seems to me again that has more to do with the context of what is
> happening at the gui level. Presumably the thin line means that the
> line is in a buffer being draged around.  But why should the line
> care?

The line doesn't care.  The GUI doesn't care either.  The drag-n-drop
code cares, so it's the one that tells the GUI how to draw the line.