Re: gEDA-user: General Layers questions

[Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx>]

DJ Delorie <dj@xxxxxxxxxxx> writes:

>> > 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*.

But we cannot know what is necessary.

>> 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 :-)

>> 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.

Why not?  The tool can move it arount and not much else, like with all
objects on a sliklayer.

But that's why I argue for hole layers. A hole is a shape on a hole
layer.  The layers attributes define what needs to be drilled.
Actually, they only define to which layers they electrically conduct.
That is all the tools needs to know until checkout.  DRC checks if all
shapes are circles, unless the shape has a DRC overide attribute.

There would be one hole layer for each drill pattern, i.e., one, unless
there are partial vias.  John's insulating layers will be mentioned in
the attributes, so they get drilled too.

A via with variable hole size for different layers must be built as a
composit with multiple holes on as many hole layers. Inefficient but
appropriate for such an obscure case.

>> 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?

So that everything is just shapes on layers. Very simple, very powerful.

>> 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?

The memory core representation provides methods to move, rotate, mirror
shapes and composits.  (Element composits may have an attribute that
forbids mirroring.)  To bring an element to the other side od the board
is method of the Element plugin, relying on attributes of the relevant
layers how they map to the other side.

I don't think that the concept of vias and elements shall be fully
implemented in plugins, for efficiency, and since most other plugings
may need refer to these concepts.  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.


-- 
Stephan


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user