> > I expect the plugin mechanism to be the way to write *all* the core > > bits, though. > > The more important it is, that what is below the plugin mechanism is as > general as necessary, and since that is difficult to judge up front: as > general as possible, without compromising the final goals.
As general as neccessary, but not as general as *possible*. > 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. > It provides basic operations on these concepts. The implementation of > these concepts builds on the objects of the storage data layers. It > must not be an error if a via has two holes, a polygon shaped hole or > silk in it. DRC may flag such things, but it must not be an error. There must be *some* limits, however, or the tools cannot be written. Defining a "hole" in a silk layer is nonsensical, if you wish to support it, we cannot define what the tools would do with it. > The attributes that this memory representation and it methods > understand shall be in namespace "pcb:" and unknown attributes in > that namespace shall emit warnings. You assume that attributes are the way to organize groups of things. Why? > Higher level parts of the concepts "element", "via", "surface layer" > may be implemented in plugins. How does a move tool plugin interact with an element plugin, then? _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
