[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