[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: General Layers questions
> > As general as neccessary, but not as general as *possible*.
>
> But we cannot know what is necessary.
Well, we start by asking people who do pcb layouts what they need :-)
"My point exactly. Do customers *want* portable fire?"
> >> On top of that is a memory representation, that introduces the concepts
> >> of elements, vias, surface-layers (layer sets: copper, mask, silk,
> >> courtyard, keepout), connectivity, ....
> >
> > This is the part I wish we were discussing.
>
> As John said, bottom up works better in the long term :-)
WE ALL AGREE ON THE BOTTOM! Gah! This is so frustrating! WE AGREE!
Can we move on to the next step PLEASE?
> Why not? The tool can move it arount and not much else, like with all
> objects on a sliklayer.
You don't drill through ink. You drill through what the ink is *on*.
It's a semantic issue. If you want a spot where ink is missing, you
add an anti-circle there. It's different than a physical hole. It's
still a circle that removes things, but since we're designing a pcb
layout program, the semantic difference matters.
> I don't think that the concept of vias and elements shall be fully
> implemented in plugins, for efficiency,
> At least some callback hooks need to be specific to elements or
> vias, that a plugin can register. So that a plugin can intercept
> composite methods (e.g., move) for elements or vias.
*That* is my point. "For efficiency" and "composite methods" means
that we need some semantic middle-layer to our internal data. We
can't say "it's just shapes" because that's not how the user interacts
with the design.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user