> That was my impression - so it seems a bit odd to group silk and copper > together (which is how it seems to be done in both thermal.pcb and > tut1.pcb, the two files I've been using as test cases).
In the groups table, the extra two "layers" are used to associate groups with the component and solder sides of the board (so you know which copper group pads belong to). Not the same as the two extra silk layers. AFAIK the relative indices are the same for top/bottom though. > > Or add layers to or delete layers from the current board. > > How is that done? I searched the code for assignments to either > max_layer or LayerN and didn't find any except in new-board and > load-board code. What did I miss? Look up MoveLayer() (function and action). If the "from" layer is "none", it creates a layer. If the "to" layer is "none" it deletes it. > So far, they appear to be just ways to tag collections of four > distance settings to make it easy to switch between them. Pretty much. > It appears to me that there are "live" values for these four > settings, which are stored in Settings, and NUM_STYLES (why always > this many? more legacy code?) Yes. > It appears to me that the design calls for ways to copy from > RouteStyle[] to Settings and from Settings to RouteStyle[], Yes. > to change which element of RouteStyle[] is `current' (ie, affected > by the former two), Not quite. There's a "save to style" type of operation, but I don't think there's a lasting association beyond that. > - Is there always a `current' RouteStyle[] slot? That is, does the > design expect that changing the Settings values will affect the > > current RouteStyle[] slot's values too, and conversely? No. > - What is the "style" HID flag? That looks to see if the current style *happens* to match a RouteStyle. If so, it returns the index (1..N). If not, it returns zero. The idea in set_some_route_style() is that if the current style (in Settings) already matches one of the styles, fine, otherwise we set the current style to *some* entry (we arbitrarily chose the first). > I can't see any code that checks Settings against RouteStyles[] > and updates the "style" flag upon finding a match, so I must be > missing _something_ - what? FlagCurrentStyle() in flags.c. The association with the string "style" is done in the flags_flag_list[] array in that file. A lot of the PCB internal interfaces are interpreter-style designs. So, when you see a string parameter like that, it's likely there's a table associating that string to a function somewhere. _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
