This message makes me think that COW should remember what master it was copied from and an edited flag.
On Mar 18, 2011, at 5:16 PM, Stephan Boettcher <boettc...@physik.uni-kiel.de> wrote: > DJ Delorie <d...@delorie.com> writes: > >>>> Except gerbers have special cases for thermals and pads, for example. >>> >>> So there need to be attributes on shapes. >> >> No, the exporters really need to have access to the whole collection >> of shapes that means "pin" so they can do pin-specific things. If the >> exporter doesn't need that high-level access, then the default action >> breaks it down into shapes and exports them individually. >> >> The gerber exporter needs to be given a whole "pin" because it has a >> command that means "put pin here, with this aperture and thermal >> settings". If you wait until the core descends to "circle, arc, >> line", it's too late to look at the attributes and figure out what's >> happening. CAM tools know about this, and can adjust thermals and >> pins as needed, but in PCB's case they can't do it because we break >> pins down into raw shapes. > > I do not understand this. The gerber exporter exports each layer > separately, no? On some layer it finds a circle with a thermal > attribute surounded by a polygon. What else does in need? > >>>> and containing other layers as sub-layouts. I have never disagreed >>>> with this! >>> >>> Oh. My understanding of composites is different. I assume a composite >>> contains shapes that go on a global set of layers. >> >> This is part of the communication problem we're having, yes ;-) >> >> Consider these: >> >> * A footprint is a global resource, but an instance of a footprint (an >> element) must be mapped to the physical layout. When do you manage >> the footprint as an element (indivisible) and when do you access its >> parts (changing pad size)? > > Is the footprint still part of the layout? Wouldn't it's genereic > layers (top,inner,bottom) be mapped to the layout layers > (oben,innen1,innen2,unten) when imported? > >> * A sub-circuit that's replicated N times on a board. > > composites instances are objects inside other composites, next to > shapes. You can do most operations to composites, that you do to shapes > (move, rotate, mirror, delete, ...). Vias and elements are special in > the memory representation, as there are methods, or callback hooks that > allow access to some internals without explicitly decending into the > composit. It should be possible to flag any composit as Element or vise > versa, to turn on and off this special access. If you exlicitly decend > into an element, you can move its pins and pads. But pads size, text > positions e.t.c. are still directly accessible for elements. Maybe it > is not even necessary to have any special treatment and treat all > composites the same. > >> * A flex cable that has 4 layers at each end, but only 2 layers in the >> middle. The extra layers on the end are on opposite sides of the >> cable. > > You want to describe the rigid ends as outlines of a composite? That > attaches high-level semantics to a low level concept in an inapropriate > way. > > Here you need outline layers with attributes that tell the autorouters > not to cross the lines on certain layers. > >> * buried vias are limited to certain pairs of layers because of the >> way the fab is assembling the board. > > A DRC problem. With hole layers, the GUI tool to add/manipulate these > hole layers can provide a view on the layer stack that represents the > stacking and drilling order, just like you once proposed as an > underlying data structure. The tool would refuse to configure holes > layers that cannot be drilled, unless you say "please". > >> * 400 instances of a standard via, but the user needs to modify the >> pad stack on just one of them, and only for one layer. > > Vias may be COW by default, like they are now. But you can decend in > non-copy mode into the composite, so they all change. That composit is > also the master copy in the Via menu, so that future vias of that type > are affected by the edit. When you edit the via definition in the Via > menu, you may need to answer a question if you want all existing > instances to change, of only new vias. > >> These are all examples of a need for both a semantic and data >> heirarchy, where parts of your design are grouped together and treated >> as a single object, sometimes replicated, sometimes customized. What >> we call them is not important. >> >>> Well, yes, it can, except that a via is not sufficiently special to >>> justify the distiction. What would we have in a composite, the layout >>> being the top-level composite? >>> >>> Vias >>> Elements >>> Composits that are not Vias or Elements >>> Lines >>> Shapes outside of composits that are not Lines >> >> Consider: you can move a via, but for lines, you can move either the >> line or its endpoints. For a polygon you can move its corners. Ah, >> but a via can include polygons and lines - but when it's a via, you >> *don't* move their endpoints and corners, unless you specifically edit >> the via. A pin is just like a via, except you *don't* move it - you >> move the element it's in. > > shapes (lines and polys) in the current composite can be editied as > before, moved, endpoints moved, size, pcb:endcap attributes changed ... > > Some internals of composites may be accessible, like clearances and > sizes, just as before. A composite attribute may define it its COW or it > all instances are changed. Vias and Elemets are COW by default if past > behavious shall be kept. > > When you want to change something inaccessibe inside a composite, you > can decend into it, either in copy mode or non-copy mode. Everything > higher up than the edited instances may be grayed out on screen now. You > can also choose to only see the instance you are editing. Now you can > manipulate, autoroute, ... the content of the composit. There is your > footprint/via editor. > >> Now consider a differential pair. It's a line but you *don't* move >> the *line* endpoints, you move the *pair* control points. > > That is a hard one. You could define a composit of type "morphable" The > endpoints of shapes inside such a composite become pointable/selectable, > and a plugin can register callbacks to be called when such an endpoint > is manipulated. The plugin would check to see if a "diffpair" attribute > is set, and decline the callback if not, so that the "magic_poly" plugin > has a chance. > >> So yes, a via is special. Many other composite objects will be >> special too, because the tools need to know what the appropriate way >> of interacting with them are. PCB layout is *not* a paint program, >> it's a design tool. It *must* understand "the design" if it's to be >> the most useful to the user. >> >>> When an how to map generic element layers to layout layers is >>> another good question. >> >> Yup. >> >>> Global layers can be mapped at load time. Local layers inside >>> composits must be mapped a runtime, don't they? >> >> The mapping can be computed at load time, and just stored. I suspect >> there'll be lots of "recurse through the data heirarchy" code. > > > > ... 21 new messages in my inbox > > -- > Stephan > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user