Re: gEDA-user: General Layers questions

[Steven Michalske <smichalske@xxxxxxxxx>]

On Mar 18, 2011, at 3:22 PM, Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx> wrote:

> DJ Delorie <dj@xxxxxxxxxxx> writes:
> 
>>> ... I think the tool we have is pretty good already. Very good.  Thanks!
>> 
>> The tool we have already is nearly impossible to maintain, though.
>> 
>>> Please do not expect that users write plugins.  The tool is already too
>>> good as it is to make is worth the effort to learn how to do that.
>> 
>> 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.
> 
> I'd propose a very basic, very general storage data representation.
> Just layers, shapes, and arbitray levels of composites, the layout
> implicitly being the top level composit. Everything with arbitrary
> attributes.
> 
> 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, ....  
> 
> 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.

Ahh, dreaming of a via that is untented, circled automatically, and net named.  Instant testpoint!  Perhaps by a testpoint tool,  that would make pads centered on a trace with the same properties.

> The attributes that this memory representation and it methods understand
> shall be in namespace "pcb:" and unknown attributes in that namespace
> shall emit warnings.


> 
> The plugins define their own attributes.  Attributes shall not be
> overloaded.  If a plugin operates on attributes of the memory
> representation, it shall do that via methods of that representation, if
> possible.  
> 
> Higher level parts of the concepts "element", "via", "surface layer"
> may be implemented in plugins.
> 
> 
> 
> 
> I cannot keep up, there are 15 new messages in my inbox, lets see what
> what new arguments come up :-)
> 
> I cannot make up my mind if I should continue to argue for hole layers,
> or if holes shall be shapes with hole attribute on layers.
> 
>> The fact that the *user* can write them *also* is a side-effect :-)
>> 
>> 
>> _______________________________________________
>> geda-user mailing list
>> geda-user@xxxxxxxxxxxxxx
>> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 
> -- 
> Stephan BÃttcher                     FAX: +49-431-85660
> Extraterrestrische Physik            Tel: +49-431-880-2508
> I.f.Exp.u.Angew.Physik               mailto:boettcher@xxxxxxxxxxxxxxxxxx
> Leibnizstr. 11, 24118 Kiel, Germany
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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