> > 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
