[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: General Layers questions



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