Index: trunk/doc/conf/groups.html =================================================================== --- trunk/doc/conf/groups.html (nonexistent) +++ trunk/doc/conf/groups.html (revision 5594) @@ -0,0 +1,116 @@ + + +

The new config system in pcb-rnd

+

grouping - flat vs. tree

+The original settings and HID attribute system in pcb were both flat: +basically a list of type:key=val triplets. All settings in a few big bags; +which bag sometimes doesn't depend on some logical categorizing, but +historical reasons (e.g. which part of the code needs the given setting). +

+This works well for a small amount of settings but lack of categories or +hierarchy (or sets or groups) makes it harder to understand what setting does +what and orients users to just accept defaults. After a while it also +makes programmers think twice before adding a new setting, increasing the +crowd in a bag. This in turn results in a less configurable +system. +

+Introducing a hierarchy of settings can solve these problems by grouping +and categorizing settings. If the user is interested in how footprints are +searched, they can ignore the settings the editor/ subtree has. It is also +easier to save and reload selectively: when the hierarchy is done right, +closely related settings end up in the same category (thus the same subtree). +Thus saving or loading a subtree can fully save or restore a property of the +program, even if that property is affected by multiple settings. + +

pcb-rnd config tree

+The config tree, the full tree is, something that exists in memory. Actual +config files often contain only a subset of the tree. Multiple config files +(e.g. system level, user level, settings from the .pcb file) are loaded and +merged to form the final config tree. The hierarchy of the tree is represented +by setting groups, which are like directories on a file system. Actual settings +are always leaves of the tree, placed in a specific group at any level (just +like in file systems). A full path to a setting is written like a +path on a file system: group1/group2/item, where group1 and group2 are +names of setting groups and item is the name of the setting. Note: unlike +with real file systems, the leading slash (representing the root) is omitted. +

+Details/constraints: +A valid path unambiguously identifies a setting (or a setting group). Settings +and groups always have exactly one parent (except for the root group that +has no parent). There is only one root of the config tree. +

+The main groups in the logical tree are: + +

+ +
(root)   (config root) +
|       +
+- rc run control (program startup) +
|       +
|   |   +
|   +- path paths automatically set up by the program at startup - do not specify these +
|       +
+- design some default settings of a new design; minimum/maximum value of some design settings +
|       +
+- editor how the pcb editor behaves - independent of HIDs or the GUI +
|   |   +
|   +- increments_mm interactive increment/decrement steps when active unit is mm +
|   |   +
|   +- increments_mil interactive increment/decrement steps when active unit is mil +
|   |   +
|   +- view default view parameters +
|       +
+- appearance how the GUI looks like - common to all GUI HIDs +
|   |   +
|   +- color layer colors, GUI colors, misc design colors +
|   |   +
|   +- pinout pin label properties +
|   |   +
|   +- messages message window properties +
|   |   +
|   +- misc non-GUI settings handled by the GUI HIDs +
|       +
+- plugins dynamic subtree for various plugin settings +
|   |   +
|   +- foo all settings of the imaginary foo plugin are registered in this group +
|       +
+- utils dynamic subtree for various plugin settings +
  |   +
  +- bar all settings of the imaginary bar utility are registered in this group +
+
+ +

dynamic subtrees

+ +The plugins/ and utils/ subtree are dynamic, which means their contents +are not defined by core pcb. +

+In plugins/ each plugin should create a group for its own settings. What +this subtree should contain depends on what plugins are actually loaded. +The benefit of this approach is that plugins can use the central config +infrastructure instead of inventing their own config files. This makes +user's life easier on many levels: single config syntax to learn; uniform +GUI (gtk HID's preferences window) to change all settings; uniform way to +save/restore parts of the settings. +

+The utils/ subtree is very similar in all aspects except that it is for +external utility programs. Utils that are closely related to pcb-rnd, such +as gsch2pcb-rnd, should work from the same configuration (e.g. to +make sure the same footprint paths are searched). If they already load the +pcb-rnd config files it's easier to keep their settings in the same tree, +in the same format. +

+Pcb-rnd doesn't generate warning for unrecognized settings in dynamic subtrees. +This lets the user configure plugins that are not always loaded and let util +settings sit in their subtree. + +

what happens to all these settings

+ +After loading all config files they are merged: if the same setting is +described in multiple files, the higher priority wins or if the setting is +a list (e.g. library search paths) the items are merged in a final list. +At this point the full logical config tree is built. Next the textual values +from the logical tree are converted into binary (native C values like +"long int" or "double") and are saved in C variables for the code to +access them directly. + Index: trunk/doc/conf/index.html =================================================================== --- trunk/doc/conf/index.html (nonexistent) +++ trunk/doc/conf/index.html (revision 5594) @@ -0,0 +1,92 @@ + + +

The new config system in pcb-rnd

+

Why, what was wrong with the old one?

+The old config system had several limitations that would have been +hard to fix keeping the original design: + + +

What the new system offers

+ + +

How to get started

+ + + +

But isn't this more complicated for the user?

+Hopefully not much. There are a few extra features, like +multiple sources with levels that did not +exist in pcb and lists with prepend/append. Some of these +features present in other software so users should be comfortable with the ideas. +The learning curve is probably compensated by the more orthogonal system. +The syntax is also geared for simplicity and easy use with text editors. +Finally, the new preferences dialog in the GTK HID and config actions help +the user to explore how settings got used from all the config sources. There's +an intended layering in complexity: simple things can be done easily without +having to understand the whole system. +

+All in all, the extra features the user needs to learn is comparable with +the old customs that he/she can forget. + +

And did it make the code more complicated?

+The size of the code did not change much after the initial config rewrite. +The new system has new features, some of which brought in a few hundred lines of +code, but a similar amount of old code could be removed. What came in is +infrastructure, what had to go was a bunch of repetitive config parsing, +boolean-setting-accessor-action code. This means on the long run, the more +settings are added, the more the new system pays back. +

+Read access, which is far the most common way to use the config in the +code (e.g. if (setting == true) { }) is very similar to the old Settings +system. Write access needs to go through a function call API, but this +is usually a single call per setting (instead of directly modifying a +variable). +

+For plugin programmers, the new system makes life much easier as they can +plug their settings in. + + +

Compatibility with mainline

+ +None. The new configuration system uses a new logical structure, new file +format, new locations on the file system. Most setting names are the same +or very similar to the old ones. Some settings are renamed for clarity: +clearance is always called clearance, on the UI, in the code and in +config files as well (mainline pcb sometimes call it keepaway).The new, +tree-based logics adds a twist too: full names of settings are paths. + +

+ +Since configuration is stored in new files, pcb-rnd settings do not interfere +with pcb settings on any level. + + + Index: trunk/doc/conf/index_prog.html =================================================================== --- trunk/doc/conf/index_prog.html (nonexistent) +++ trunk/doc/conf/index_prog.html (revision 5594) @@ -0,0 +1,8 @@ + + +

The new config system in pcb-rnd

+

Programmer's documentation

+ +TODO + + Index: trunk/doc/conf/index_user.html =================================================================== --- trunk/doc/conf/index_user.html (nonexistent) +++ trunk/doc/conf/index_user.html (revision 5594) @@ -0,0 +1,92 @@ + + +

The new config system in pcb-rnd

+

User documentation

+As of 1.1.0, pcb-rnd switched to a lihata based configuration system. +The purpose of this document is to describes the basic system design going into +enough details to provide the user with full control over the configuration. +The other side, how the system is implemented is described in the + programmer's manual and there is also a +checklist to assist plugin programmers. + +

Architecture: data flows, merging, dispatching

+The final configuration is a collection of values for + all known settings, arranged in a tree. The config +tree is a theoretical concept; different representations of the tree are +actually built runtime, in-memory. Pcb-rnd code, plugins and utilities +are constantly reading these in-memory representations to decide how to +carry out their tasks. +

+Config settings are imported from multiple sources: from different files, +from environment vareiables, from command line arguments, from the .pcb +files on load. Any source can define any part of the config tree. +When the configuration is processed, each source is read into a temporary +tree and then all the temporary trees are merged into the final +config tree. The following diagram demonstrates all configuration +related data flows. +

+ +

+The leftmost column of nodes are the sources. (Note: paths mentioned there are +the default paths, for reference, it is possible to change them compile-time.) +Along the black arrows, from left to right, each source is imported into a +tree representing a role: the role or +purpose of the source. The next +step is following the red arrows in two steps: + +Some components may change some of the settings run-time. The trivial example +is the GUI (hid_gtk on this diagram) that provides menus and dialog boxes for +the user to change settings. Such a change is always fed back (blue arrow) +to the design role tree directly, from where the new value is again merged +and dispatched along the red arrows. Changes in the design role are saved +with the .pcb file (thus the bidirectional black arrow between the source and +the in-memory tree for the design role). Occassionally the user wants to +save parts of the setting as a project setting or +as an user setting - in this case, along the dashed blue lines, the +corresponding project or user roles are modified. This again results in updating +the hash and the binary representation; these roles also have +bidirectional black arrows and their changes are also saved in the original +source. + +

Merge details

+In the new system it is up to the user to decide what settings are +system-level and what settings are user- or project-level. This is possible +because any source can define any setting. In the merging step (red arrows +between roles and the hash) it may turn out that there are overlaps (multiple +sources defining value for the same setting) or blind spots (no source +sets a given item). + +

overlaps

+Each setting in each source has a prioirty. The +priority can be defined in the source, or if it is not defined, each source +inherits a fallback default priority. The fallback is designed to provide +the intuitive order: cli > design > project > user > system. +

+When multiple sources are describing a value for the same setting, +priority decides the final value. Most settings are scalar: +a single integer, string or a single "yes/no" or "on/off" value (e.g. +the background color or whether polygons are thin-drawn). For scalars +the rule is simple: the higher priority value wins and all lower priority +values are discarded when putting the values into the hash. More +details: how different roles and priorities +can be used with scalars. + +

+There are some settings that are represented as an array or list of +values. They are described in a lihata list item ("li:") in the config +files and are generally called lists in this document. How lists +are merged is controlled by the merging policy, which can be +in each source, just like the prioirty is set. Check out the +list merging section for more details. + +

blind spots

+At the end the code does need a value for each setting, so in the final +render (after the hash) every setting must have a value. To avoid blind spots, +values not initialized, there is a built-in configuration file, compiled into +the executable. This file is loaded into role CFR_INTERNAL, and has +the lowest priority. This configuration file contains the default value for +all settings. + Index: trunk/doc/conf/lists.html =================================================================== --- trunk/doc/conf/lists.html (nonexistent) +++ trunk/doc/conf/lists.html (revision 5594) @@ -0,0 +1,125 @@ + + +

The new config system in pcb-rnd

+

Lists and arrays

+ +Non-scalar settings are arrays or lists. Arrays can be explicitly indexed + +The default policy is always overwrite. +

+There are three active policies: overwrite, prepend and append. +When dealing with lists: +

+Step 3 is straight-forward: if policy is overwrite, reset the output +list and copy the source's list into the output list. If policy is +prepend (or append), keep the current output list and prepend +(or append) the list provided by the source. +

+In practice this means the user can replace, prepend or append ordered lists +from various sources. A common example is setting the library search paths. + +

examples

+ +

simple overwrite

+Config sources (ordered by priority): + +
role priority policy content +
system 200 overwrite A,B,C +
user 400 overwrite (not defined) +
project 600 overwrite D,E +
+

Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A,B,C   +
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change +
3. apply project D,E replace the original output because of the overwrite policy +
+

Example scenario: the project is restricted to local footprint libs; this setup +makes sure no system or user configuration injects external footprint paths. + +

empty overwrite

+Config sources (ordered by priority): + +
role priority policy content +
system 200 overwrite A,B,C +
user 400 overwrite (not defined) +
project 600 overwrite defined to be an empty list +
+

Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A,B,C   +
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change +
3. apply project (empty) replace the original output because of the overwrite policy +
+ +

prepend

+Config sources (ordered by priority): + +
role priority policy content +
system 200 overwrite A,B,C +
user 400 prepend (not defined) +
project 600 prepend D,E +
+

Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A,B,C   +
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change +
3. apply project D,E,A,B,C   +
+

Example scenario: the project has its own footprint libs with two paths; these +should be searched before system and user paths, still, system path is also +kept so stock footprints can be found. +

+This is better than hardwiring A,B,C in the project's list: A, B and C may +depend on the installation on a given system. A project file has no idea +about how the system is installed but it is assumed system installation +and the system configuration file are consistent. + +

append

+Config sources (ordered by priority): + +
role priority policy content +
system 200 overwrite A,B,C +
user 400 append (not defined) +
project 600 append D,E +
+

Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A,B,C   +
2. apply user A,B,C "not defined" doesn't mean "empty", so the list is not deleted - no change +
3. apply project A,B,C,D,E   +
+

Example scenario: the project has its own footprint libs with two paths; these +should be searched after system and user paths. This means the local footprint +lib has lower priority than the stock footprints. See system-dependent +installation remarks in the previous point. + + +

prepend+append

+Config sources (ordered by priority): + +
role priority policy content +
system 200 overwrite A,B,C +
user 400 prepend X,Y,Z +
project 600 append D,E +
+

Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A,B,C   +
2. apply user X,Y,Z,A,B,C   +
3. apply project X,Y,Z,A,B,C,D,E   +
Index: trunk/doc/conf/merging.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/conf/merging.png =================================================================== --- trunk/doc/conf/merging.png (nonexistent) +++ trunk/doc/conf/merging.png (revision 5594) Property changes on: trunk/doc/conf/merging.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/conf/noextend.html =================================================================== --- trunk/doc/conf/noextend.html (nonexistent) +++ trunk/doc/conf/noextend.html (revision 5594) @@ -0,0 +1,59 @@ + + +

The OLD config system in pcb-rnd

+

If the config system is too static

+ +This document describes the old situation, focusing on drawbacks for +a purpose: to give a hint on why some of the design decisions are made +the way they are, in the new conf system. + +

Settings, preferences, colors, and...

+The core implemented a so called Settings. It was a flat list of items, +each bound to a C variable. There was a bunch of metadata attached to +the items: name, type, description. Generic code could query or change +the value of any setting, the C code could read and write them directly +too. The content is saved to ~/.pcb/settings. +

+On the downside, the actual items this system knew about was pretty much +static, hardwired in core. A plugin could not register its own settings. +Multiple parallel methods were present in the code to overcome this +limitation: +

+ +

Meta-drawbacks

+This also introduced a more subtle drawback: the configuration was now +scattered into different files, randomly (looking from the +user's point of view). In other words, the actual structure did not reflect +some logical grouping, but mostly historical or source code organizational +reasons. +

+In turn, this also limited (again somewhat randomly) what settings can be +stored system-wise, user-wise, or on project or design level. +

+Finally, handling of file search paths was not very sophisticated. There +was the system and user configuration that reflected where the stock +library or the user's generic library were installed. And then +there was the per-project local footprint libs that had to be somehow +added too. +

+There was a hardwired way of handling the situation where multiple set +of paths were specified. In practice it was usually possible to get this +to work for the simpler cases, but it was not powerful enough to express +things like "use all system and user libraries first, then the project's local +library" vs. "the project's local library has priority over system libraries". Index: trunk/doc/conf/plugin_chk.html =================================================================== --- trunk/doc/conf/plugin_chk.html (nonexistent) +++ trunk/doc/conf/plugin_chk.html (revision 5594) @@ -0,0 +1,7 @@ + + +

The new config system in pcb-rnd

+

Plugin programmer's checklist

+ +TODO + Index: trunk/doc/conf/prio.html =================================================================== --- trunk/doc/conf/prio.html (nonexistent) +++ trunk/doc/conf/prio.html (revision 5594) @@ -0,0 +1,22 @@ + + +

The new config system in pcb-rnd

+

Priorities

+ +Priority is an integer property of each config root. +Syntax-wise it is part of the name of the config +root. In the lihata config file it is either specified or omitted. When +omitted, a role dependent default value is +used. The default values are chosen in an intuitive way, thus most +commonly the priority value is omitted. +

+For scalar settings, the highest priority +value determines the final value of a setting after the merge. If there +is a tie, role decides: the role closer to the CLI is stronger. +

+For lists and arrays, priority determines the +order of merge, which changes the order of itmes in the final list as +config roots prepend and append items. + + + Index: trunk/doc/conf/scalars.html =================================================================== --- trunk/doc/conf/scalars.html (nonexistent) +++ trunk/doc/conf/scalars.html (revision 5594) @@ -0,0 +1,56 @@ + + +

The new config system in pcb-rnd

+

Scalars

+ +Scalar settings have only one value after the merge. The only policy +available is overwrite - this policy is applied regardless of the +current policy setting. + +

examples

+ +

simple overwrite

+Config sources: + +
role priority policy content +
system 200 overwrite A +
user 400 overwrite (not defined) +
project 600 overwrite Q +
+

+Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A   +
2. apply user A "not defined" doesn't mean "empty", so the list is not deleted - no change +
3. apply project Q replace the original output because of the overwrite policy +
+

Example scenario: system default overriden by a project setting. + +

user-forced value

+Config sources append: + +
role priority policy content +
system 200 overwrite A +
user 650 overwrite E +
project 600 overwrite Q +
+

+Merge iterations: + +
step description output list after executing this step remarks +
0. reset the output (empty)   +
1. apply system A   +
2. apply project Q   +
3. apply user E   +
+

Example scenario: user preference enforced: even if the project file would use +'Q' for the given setting, the user prefers 'E'. This affects runtime +(the value of the setting after the merge, in other words how pcb-rnd works), +but does nto change the project configuration. This allows the given user to +always use 'E' for the given setting while lets other users working on the +same project use the value set in the project file. + + + Index: trunk/doc/conf/sources.html =================================================================== --- trunk/doc/conf/sources.html (nonexistent) +++ trunk/doc/conf/sources.html (revision 5594) @@ -0,0 +1,72 @@ + + +

The new config system in pcb-rnd

+

Sources

+There are different sources of configuration settings. These are +different configuration files, sometimes located on the file system. +The full list of config sources is: + + +
role default
setting
prio 		location presence remarks +
internal + 100 + (compiled into the executable) + always + the ultimate fallback; allows pcb-rnd even if no other configuration file is found + + +
system + 200 + /usr/share/pcb-rnd/pcb-conf.lht + recommended + should hold system and installation specific settigns, e.g. path to the system-wise installed footprint library + +
default.pcb + 300 + /usr/share/pcb-rnd/default.pcb + deprecated + pcb editable defaults + +
user + 400 + ~/.pcb-rnd/pcb-conf.lht + recommended + store user preferences, user's common footprint lib path, etc; this is the first file the user can modify (even from the GUI) + +
environment + 500 + environment variables (TODO) + occassional + inject the same (temporary) settings in multiple pcb-rnd sessions without having to change config files + +
project + 600 + projdect.lht in the project directory + optional + local project settings - useful for large projects with multiple design (.pcb) files + +
design + 700 + saved in the design (.pcb) file + optional, common + per design deviation from the user+system config + +
cli + 800 + command line argument + occassional + inject/change a setting for a single session; useful in batch/automated processing +
+ +

+Pcb-rnd reads them all, then merges all settings into a master binary +representation. If a setting is specified in multiple sources, the one +with the higher priority wins, except for lists where it is also possible +to prepend/append items. Default priorities are designed to result +precedence in an intuitive way (e.g. design settigns overwrite user settings). +However, priority can be changed per setting, resulting +in weak settings ("use this value if it was not already set") or strong settings +("I always want to use mincut, so I enable it from my user's config with high +priority and a version controlled project setting can not turn it off") + + Index: trunk/doc/conf/src/Makefile =================================================================== --- trunk/doc/conf/src/Makefile (nonexistent) +++ trunk/doc/conf/src/Makefile (revision 5594) @@ -0,0 +1,2 @@ +../merging.png: merging.dot + dot -Tpng merging.dot > ../merging.png \ No newline at end of file Index: trunk/doc/conf/src/merging.dot =================================================================== --- trunk/doc/conf/src/merging.dot (nonexistent) +++ trunk/doc/conf/src/merging.dot (revision 5594) @@ -0,0 +1,103 @@ +digraph g { + rankdir=LR; + + subgraph cluster_memtree { + label="in-memory lihata trees" + bgcolor=grey + rank=same + CFR_INTERNAL [label="CFR_INTERNAL\nultimate fallback"] + CFR_SYSTEM [label="CFR_SYSTEM\nsystem level configuration"] + CFR_DEFAULTPCB [label="CFR_DEFAULTPCB"] + CFR_USER [label="CFR_USER\nuser level configuration"] + CFR_ENV [label="CFR_ENV"] + CFR_PROJECT [label="CFR_PROJECT\nproject level configuration"] + CFR_DESIGN [label="CFR_DESIGN"] + CFR_CLI [label="CFR_CLI"] + } + + subgraph cluster_fields { + label="string -> conf_native_t hash" + bgcolor=grey + conf_fields [label="conf_fields\ncentral hash\nof all\nknown settings"] + } + + subgraph cluster_native { + label="native C structures\nper module" + bgcolor=grey + conf_core [label="conf_core\npcb-rnd core settings"] + conf_hid_gtk [label="conf_hid_gtk\nthe hid_gtk plugin's settings"] + conf_mincut [label="conf_mincut\nthe mincut plugin's settings"] + conf_report [label="conf_report\nthe report plugin's settings"] + conf_other [label="...\nother plugin's settings"] + } + + CFR_INTERNAL -> conf_fields [color=red] + CFR_SYSTEM -> conf_fields [color=red] + CFR_DEFAULTPCB -> conf_fields [color=red] + CFR_USER -> conf_fields [color=red] + CFR_ENV -> conf_fields [color=red] + CFR_PROJECT -> conf_fields [color=red] + CFR_DESIGN -> conf_fields [color=red] + CFR_CLI -> conf_fields [color=red] + + +# CFR_INTERNAL -> CFR_SYSTEM +# CFR_SYSTEM -> CFR_DEFAULTPCB +# CFR_DEFAULTPCB -> CFR_USER +# CFR_USER -> CFR_ENV +# CFR_ENV -> CFR_PROJECT +# CFR_PROJECT -> CFR_DESIGN +# CFR_DESIGN -> CFR_CLI + + conf_fields -> conf_core [color=red] + conf_fields -> conf_hid_gtk [color=red] + conf_fields -> conf_mincut [color=red] + conf_fields -> conf_report [color=red] + conf_fields -> conf_other [color=red] + + + + subgraph cluster_files { + label="config files" + bgcolor=grey + lht_system [label="/usr/share/pcb-rnd/pcb-conf.lht" shape=hexagon] + pcb_default [label="/usr/share/pcb-rnd/default.pcb" shape=hexagon] + project [label="./project.lht" shape=hexagon] + lht_user [label="~/.pcb-rnd/pcb-conf.lht" shape=hexagon] + } + + subgraph cluster_exec_env { + label="execution environment" + bgcolor=grey + env [label="environmental variables"] + cli [label="command line arguments\ne.g. -c or\npluginspecific args"] + } + + lht_internal [label="hardwired\nin the\nexecutable"] + design [label="settings\nin the\n.pcb file" shape=hexagon] + + lht_internal -> CFR_INTERNAL [label="program startup"] + lht_system -> CFR_SYSTEM [label="loaded at startup"] + pcb_default -> CFR_DEFAULTPCB [label="loadad in CreateNewPCB()"] + lht_user -> CFR_USER [label="loaded at startup" dir=both] + env -> CFR_ENV [label="built at startup"] + project -> CFR_PROJECT [label="loaded when a\nnew .pcb or project\nis loaded" dir=both] + design -> CFR_DESIGN [label="extracted when loading a design" dir=both] + cli -> CFR_CLI [label="built during\ncommand line argument\nparsing"] + + + hid_gtk [label="the GTK HID"] + + conf_core -> hid_gtk [weight=100] + conf_hid_gtk -> hid_gtk + + hid_gtk -> CFR_DESIGN [color=blue weigth=0] + hid_gtk -> CFR_PROJECT [color=blue weigth=0 style=dashed] + hid_gtk -> CFR_USER [color=blue weigth=0 style=dashed] + + + editor [label="core:\nediting pcb"] + conf_core -> editor [weight=100] + editor -> CFR_DESIGN [color=blue weigth=0] + +} \ No newline at end of file Index: trunk/doc/conf/syntax.html =================================================================== --- trunk/doc/conf/syntax.html (nonexistent) +++ trunk/doc/conf/syntax.html (revision 5594) @@ -0,0 +1,45 @@ + + +

The new config system in pcb-rnd

+

Config file syntax

+ +The config file sytnax is lihata. +Most users don't need to understand most of the syntax, just follow the +patterns seen in the examples. A few thumb of rules: + + +

config root syntax

+

+A pcb-rnd config file, (or document for short) has a single root +node whose name must be li:pcb-rnd-conf-v1 - this is the signature of the +document. It is a flat list of one or more config root/ subtrees. +TODO: is this really a list or a hash? +

+Each config root is a partial description of the + config tree (which is the logical +confgiuration of all possible settings). Config roots have a policy and +a priority attached. This is done in the name +of the config root, which must be of the form of policy-priority, +e.g. "overwrite-300" or "append-125". The priority part (with the dash) +can be omitted (and then the per role default priority is used), e.g. +"overwrite" or "append" are valid config root names. +

+Under the config root, a tree of sections (hashes) and setting values +(text nodes) are built. These structures and values are in 1:1 +correspondance with the config tree. Excess +(unknown) keys are considered a warning (except in the plugin/ and +utils/ subtrees). Missing keys or missing subtrees is normal because a config +root can be partial. +

+TODO: examples + +

list syntax

+TODO: list syntax + +

in project files

+TODO Index: trunk/doc/conf/tree/CFN_BOOLEAN.html =================================================================== --- trunk/doc/conf/tree/CFN_BOOLEAN.html (nonexistent) +++ trunk/doc/conf/tree/CFN_BOOLEAN.html (revision 5594) @@ -0,0 +1,8 @@ + + +

pcb-rnd conf tree

+

type: boolean

+Boolean value: true or false. Most often used for determining whether a +feature or a (display mode) is enabled. +

+Example values: true, false, on, off, yes, no, 1, 0. Index: trunk/doc/conf/tree/CFN_COLOR.html =================================================================== --- trunk/doc/conf/tree/CFN_COLOR.html (nonexistent) +++ trunk/doc/conf/tree/CFN_COLOR.html (revision 5594) @@ -0,0 +1,9 @@ + + +

pcb-rnd conf tree

+

type: color

+A color description. Use the "webcolor" format: #rrggbb, where +rr, gg and bb are 2 digit hexadecimal values for red, green and blue +components. +

+Example values: #ff0000 for red, #555555 for grey. Index: trunk/doc/conf/tree/CFN_COORD.html =================================================================== --- trunk/doc/conf/tree/CFN_COORD.html (nonexistent) +++ trunk/doc/conf/tree/CFN_COORD.html (revision 5594) @@ -0,0 +1,10 @@ + + +

pcb-rnd conf tree

+

type: coord

+A coordinate: size, distance, spacing. A decimal number with an unit. Unit +can be metric (e.g. mm, cm, m) or imperial (e.g. mil). +

+Example values: 1.5mm, 15 mil + + Index: trunk/doc/conf/tree/CFN_INCREMENTS.html =================================================================== --- trunk/doc/conf/tree/CFN_INCREMENTS.html (nonexistent) +++ trunk/doc/conf/tree/CFN_INCREMENTS.html (revision 5594) @@ -0,0 +1,8 @@ + + +

pcb-rnd conf tree

+

type: increments

+A collection of coordinates representing an increment configuration. +

+TODO + Index: trunk/doc/conf/tree/CFN_INTEGER.html =================================================================== --- trunk/doc/conf/tree/CFN_INTEGER.html (nonexistent) +++ trunk/doc/conf/tree/CFN_INTEGER.html (revision 5594) @@ -0,0 +1,10 @@ + + +

pcb-rnd conf tree

+

type: integer

+A decimal integer value without unit. The value might be stored in a +32 bit integer; safe range is approximately -2^31 .. 2^31. +

+Example values: 4, 1500, 2545343, -6 + + Index: trunk/doc/conf/tree/CFN_LIST.html =================================================================== --- trunk/doc/conf/tree/CFN_LIST.html (nonexistent) +++ trunk/doc/conf/tree/CFN_LIST.html (revision 5594) @@ -0,0 +1,10 @@ + + +

pcb-rnd conf tree

+

type: list

+An ordered list of strings. +

+Example values: +

+li:{ foo; bar; {foo/bar/with-punctuation}; 123}
+
Index: trunk/doc/conf/tree/CFN_REAL.html =================================================================== --- trunk/doc/conf/tree/CFN_REAL.html (nonexistent) +++ trunk/doc/conf/tree/CFN_REAL.html (revision 5594) @@ -0,0 +1,9 @@ + + +

pcb-rnd conf tree

+

type: real

+A decimal numeric value without unit. +

+Example values: 3.141592654, 5, -12, 0 + + Index: trunk/doc/conf/tree/CFN_STRING.html =================================================================== --- trunk/doc/conf/tree/CFN_STRING.html (nonexistent) +++ trunk/doc/conf/tree/CFN_STRING.html (revision 5594) @@ -0,0 +1,13 @@ + + +

pcb-rnd conf tree

+

type: string

+Text value. +

+Example values: +

+foo
+bar
+{long text with / punctuation?}
+
+ Index: trunk/doc/conf/tree/CFN_UNIT.html =================================================================== --- trunk/doc/conf/tree/CFN_UNIT.html (nonexistent) +++ trunk/doc/conf/tree/CFN_UNIT.html (revision 5594) @@ -0,0 +1,9 @@ + + +

pcb-rnd conf tree

+

type: unit

+Name of a unit. +

+Example values: mm, cm, m, mil + + Index: trunk/doc/conf/tree/appearance.html =================================================================== --- trunk/doc/conf/tree/appearance.html (nonexistent) +++ trunk/doc/conf/tree/appearance.html (revision 5594) @@ -0,0 +1,8 @@ + +

pcb-rnd conf tree

+

subtree: appearance

+ +
node name type flags description +
rat_thickness coord 0 +
mark_size coord 0 relative marker size +
Index: trunk/doc/conf/tree/appearance_color.html =================================================================== --- trunk/doc/conf/tree/appearance_color.html (nonexistent) +++ trunk/doc/conf/tree/appearance_color.html (revision 5594) @@ -0,0 +1,30 @@ + +

pcb-rnd conf tree

+

subtree: appearance/color

+ +
node name type flags description +
black color 0 +
white color 0 +
background color 0 background and cursor color ... +
crosshair color 0 different object colors +
cross color 0 +
via color 0 +
via_selected color 0 +
pin color 0 +
pin_selected color 0 +
pin_name color 0 +
element color 0 +
element_nonetlist color 0 +
rat color 0 +
invisible_objects color 0 +
invisible_mark color 0 +
element_selected color 0 +
rat_selected color 0 +
connected color 0 +
off_limit color 0 +
grid color 0 +
layer color 0 +
layer_selected color 0 +
warn color 0 +
mask color 0 +
Index: trunk/doc/conf/tree/appearance_messages.html =================================================================== --- trunk/doc/conf/tree/appearance_messages.html (nonexistent) +++ trunk/doc/conf/tree/appearance_messages.html (revision 5594) @@ -0,0 +1,7 @@ + +

pcb-rnd conf tree

+

subtree: appearance/messages

+ +
node name type flags description +
char_per_line integer 0 width of an output line in characters (used by separator drawing in find.c) +
Index: trunk/doc/conf/tree/appearance_misc.html =================================================================== --- trunk/doc/conf/tree/appearance_misc.html (nonexistent) +++ trunk/doc/conf/tree/appearance_misc.html (revision 5594) @@ -0,0 +1,7 @@ + +

pcb-rnd conf tree

+

subtree: appearance/misc

+ +
node name type flags description +
volume integer 0 the speakers volume -100..100 +
Index: trunk/doc/conf/tree/appearance_pinout.html =================================================================== --- trunk/doc/conf/tree/appearance_pinout.html (nonexistent) +++ trunk/doc/conf/tree/appearance_pinout.html (revision 5594) @@ -0,0 +1,12 @@ + +

pcb-rnd conf tree

+

subtree: appearance/pinout

+ +
node name type flags description +
name_length integer 0 +
zoom real 0 +
offset_x coord 0 X offset of origin +
offset_y coord 0 Y offset of origin +
text_offset_x coord 0 X offset of text from pin center +
text_offset_y coord 0 Y offset of text from pin center +
Index: trunk/doc/conf/tree/design.html =================================================================== --- trunk/doc/conf/tree/design.html (nonexistent) +++ trunk/doc/conf/tree/design.html (revision 5594) @@ -0,0 +1,26 @@ + +

pcb-rnd conf tree

+

subtree: design

+ +
node name type flags description +
via_thickness coord 0 +
via_drilling_hole coord 0 +
line_thickness coord 0 +
clearance coord 0 +
max_width coord 0 +
max_height coord 0 +
alignment_distance coord 0 default drc size +
bloat coord 0 default drc size +
shrink coord 0 +
min_wid coord 0 +
min_slk coord 0 +
min_drill coord 0 +
min_ring coord 0 +
text_scale integer 0 text scaling in % +
poly_isle_area real 0 polygon min area +
default_layer_name string 0 +
fab_author string 0 Full name of author for FAB drawings +
initial_layer_stack string 0 If set, the initial layer stack is set to this +
groups string 0 string with layergroups +
routes string 0 string with route styles +
Index: trunk/doc/conf/tree/editor.html =================================================================== --- trunk/doc/conf/tree/editor.html (nonexistent) +++ trunk/doc/conf/tree/editor.html (revision 5594) @@ -0,0 +1,49 @@ + +

pcb-rnd conf tree

+

subtree: editor

+ +
node name type flags description +
grid_unit unit 0 select whether you draw in mm or mil +
grid coord 0 grid in pcb-units +
increments_mm increments 0 increments (size deltas) when drawing in mil +
increments_mil increments 0 increments (size deltas) when drawing in mil +
zoom real 0 default zoom +
mode integer 0 currently active mode +
buffer_number integer 0 number of the current buffer +
clear_line boolean 0 new lines/arc clear polygons. +
full_poly boolean 0 new polygons are full polygons. +
unique_names boolean 0 force unique names +
snap_pin boolean 0 snap to pins and pads +
snap_offgrid_line boolean 0 Snap to certain off-grid points along a line. +
highlight_on_point boolean 0 Highlight if crosshair is on endpoints. +
show_solder_side boolean 0 mirror output +
save_last_command boolean 0 the command entry editline always starts with the last command entered by user in the current session +
line_refraction integer 0 value for line lookahead setting +
save_in_tmp boolean 0 emergency save unsaved PCB data (despite the user clicks don't save) when: user starts a new PCB; user quits pcb-rnd. Does not affect the on-crash emergency save. +
draw_grid boolean 0 draw grid points +
all_direction_lines boolean 0 enable lines to all directions +
rubber_band_mode boolean 0 move, rotate use rubberband connections +
swap_start_direction boolean 0 change starting direction after each click +
show_drc boolean 0 show drc region on crosshair +
auto_drc boolean 0 when set, PCB doesn't let you place copper that violates DRC. +
show_number boolean 0 pinout shows number +
orthogonal_moves boolean 0 move items orthogonally. +
reset_after_element boolean 0 reset connections after each element while saving all connections +
auto_place boolean 0 flag which says we should force placement of the windows on startup +
lock_names boolean 0 lock down text so they can not be moved or selected +
only_names boolean 0 lock down everything else but text so only text objects can be moved or selected +
thin_draw boolean 0 if set, objects on the screen are drawn as outlines (lines are drawn as center-lines). This lets you see line endpoints hidden under pins, for example. +
thin_draw_poly boolean 0 if set, polygons on the screen are drawn as outlines. +
local_ref boolean 0 use local reference for moves, by setting the mark at the beginning of each move. +
check_planes boolean 0 when set, only polygons and their clearances are drawn, to see if polygons have isolated regions. +
show_mask boolean 0 show the solder mask layer +
hide_names boolean 0 when set, element names are not drawn. +
description boolean 0 display element description as element name, instead of value +
name_on_pcb boolean 0 display Reference Designator as element name, instead of value +
fullscreen boolean 0 hide widgets to make more room for the drawing +
click_time integer 0 default time for click expiration, in ms +
enable_stroke boolean 0 Enable libstroke gestures on middle mouse button when non-zero +
live_routing boolean 0 autorouter shows tracks in progress +
beep_when_finished boolean 0 flag if a signal should be produced when searching of connections is done +
undo_warning_size integer 0 warn the user when undo list exceeds this amount of kilobytes in memory +
Index: trunk/doc/conf/tree/editor_view.html =================================================================== --- trunk/doc/conf/tree/editor_view.html (nonexistent) +++ trunk/doc/conf/tree/editor_view.html (revision 5594) @@ -0,0 +1,8 @@ + +

pcb-rnd conf tree

+

subtree: editor/view

+ +
node name type flags description +
flip_x boolean 0 view: flip the board along the X (horizontal) axis +
flip_y boolean 0 view: flip the board along the Y (vertical) axis +
Index: trunk/doc/conf/tree/rc.html =================================================================== --- trunk/doc/conf/tree/rc.html (nonexistent) +++ trunk/doc/conf/tree/rc.html (revision 5594) @@ -0,0 +1,26 @@ + +

pcb-rnd conf tree

+

subtree: rc

+ +
node name type flags description +
verbose integer 0 +
quiet integer 0 print only errors on stderr +
backup_interval integer 0 time between two backups in seconds +
font_command string 0 file name template; if not empty, run this command and read its outout for loading the font; %f is the file name +
file_command string 0 file name template; if not empty, run this command and read its outout for loading a pcb file; %f is the file name, %p is the conf setting rc.file_path +
file_path string 0 +
library_shell string 0 +
library_search_paths list 0 +
emergency_name string 0 file name template for emergency save anonymous .pcb files (when pcb-rnd crashes); optional field: %ld --> pid; must be shorter than 240 characters. Don't do emergency save if this item is empty. +
backup_name string 0 file name template for periodic backup anonymous .pcb files; optional fields: %P --> pid +
save_command string 0 command to pipe the pcb, footprint or buffer file into, when saving (makes lihata persist impossible) +
keep_save_backups boolean 0 a copy is made before a save operation overwrites an existing file; if this setting is true, keep the copy even after a successful save +
default_font_file list 0 name of default font file (list of names to search) +
default_pcb_file list 0 +
script_filename string 0 PCB Actions script to execute on startup +
action_string string 0 PCB Actions string to execute on startup +
rat_path string 0 +
rat_command string 0 file name template; if not empty, run this command and read its outout for loading a rats; %f is the file name, %p is the rc.rat_path conf setting +
preferred_gui list 0 if set, try GUI HIDs in this order when no GUI is explicitly selected +
have_regex boolean 0 whether we have regex compiled in +
Index: trunk/doc/conf/tree/rc_path.html =================================================================== --- trunk/doc/conf/tree/rc_path.html (nonexistent) +++ trunk/doc/conf/tree/rc_path.html (revision 5594) @@ -0,0 +1,12 @@ + +

pcb-rnd conf tree

+

subtree: rc/path

+ +
node name type flags description +
prefix string 0 e.g. /usr/local +
lib string 0 e.g. /usr/lib/pcb-rnd +
bin string 0 e.g. /usr/bin +
share string 0 e.g. /usr/share/pcb-rnd +
home string 0 user's home dir, determined run-time +
exec_prefix string 0 exec prefix path (extracted from argv[0]) +
Index: trunk/doc/conf/tree/temp.html =================================================================== --- trunk/doc/conf/tree/temp.html (nonexistent) +++ trunk/doc/conf/tree/temp.html (revision 5594) @@ -0,0 +1,7 @@ + +

pcb-rnd conf tree

+

subtree: temp

+ +
node name type flags description +
rat_warn boolean 0 rats nest has set warnings +
Index: trunk/doc/developer/c89.html =================================================================== --- trunk/doc/developer/c89.html (nonexistent) +++ trunk/doc/developer/c89.html (revision 5594) @@ -0,0 +1,14 @@ + + +

pcb-rnd - C89

+ +The code is written in C, namely C89 for most parts with a few exceptions +written in C99. It's not yet decided whether the code will be C89 or C99 +long term. If it'll be C89, the C99 parts will be rewritten. If it'll be +C99, new code can use C99 features freely. Until the decision, keep +new code C89. Especlially watch out for these: + Index: trunk/doc/developer/data.html =================================================================== --- trunk/doc/developer/data.html (nonexistent) +++ trunk/doc/developer/data.html (revision 5594) @@ -0,0 +1,103 @@ + + + +

pcb-rnd internals

+ +

concepts

+ +Convention: typedef'd types are called pcb_*_t - the corresponding struct +is pcb_*_s. + +

board

+There is only one board being edited. A board is the model of the whole world +for pcb-rnd - any other, auxiliary data is only a partial description of a board. +The data struct for board is pcb_board_t. As of now, pcb-rnd edits only one +board at a time, and it is stored in a global variable called PCB. +The code is single threaded and is not reentrant. +

+Half of the board structure describes global board properties: +

+The other half is the actual board data, stored in a pcb_data_t field. +

+Relevant structs, variables and functions are in board.[ch]. + +

data

+A pcb_data_t contains everything to describe a "subcircuit" related +to an existing board: + +

+Relevant structs, variables and functions are in data.[ch]. + +

buffers

+Paste buffers are pcb_buffer_t; the main field is pcb_data_t. +

+Relevant structs, variables and functions are in buffer.[ch]. + +

terminology: layers and layer groups

+Layers are abstract canvases also serving as a logical grouping +of drawing primitives. Every layer is part of exactly one layer +group. A layer group is close to what a physical layer is on +the FR4. +

+Limitations: +

+

+The location of a layer group on of: +

+

+In pcb-rnd only copper layers and the outline layer are fully explicit. +There are two hardwired silk layers, one for the top and one for the bottom side. +The silk layers are semi-explicit: they are existing layers in all structs +but: +

+

+The outline layer is a hack: it's really an internal copper layer. If +the code detects the name of the layer is "outline" anywhere, it branches. +

+There are a few virtual layers: +

+ +

pcb_data_t: global data

+Global data affect all layers. The most trivial example is via: +it has a hole and the same copper ring on all layers. The other global +object pcb_data_t holds is an element. An element can have pads +on two copper layers and pins that affect all layers the same way as vias. + +

pcb_data_t: layer-local data

+The data struct has a pcb_layer_t for each logical layer, to host +the per layer objects (drawing primitives). + +

the layer struct

+Layer data is stored in struct pcb_layer_t. A layer has a list +for each object type (drawing primitive type): arcs, lines, polygons, etc. +

+Relevant structs, variables and functions are in layer.[ch]. + +

map

+ Index: trunk/doc/developer/data1.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/developer/data1.png =================================================================== --- trunk/doc/developer/data1.png (nonexistent) +++ trunk/doc/developer/data1.png (revision 5594) Property changes on: trunk/doc/developer/data1.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/developer/ddrc/examples1.txt =================================================================== --- trunk/doc/developer/ddrc/examples1.txt (nonexistent) +++ trunk/doc/developer/ddrc/examples1.txt (revision 5594) @@ -0,0 +1,54 @@ +# Example 1: Sensitive RF elements should be close +# +# e1 is the list of elements that have the user tag RF +# e2 is a copy of e1; it's needed to get two loops (e1 vs. e2 objects form pairs) +# Assert that any two components are closer than 25 mm to each other + +rule sensitive RF elements + let e1 (type(@, element)) && (@.a.group == "RF") + let e2 e1 + assert (distance(e1, e2) < 25 mm) + +# Example 2: matched trace lengths on dram data 0 +# +# e1 is the list of dram traces +# e2 is a copy of e1 (see Example 1) +# Assert that any two net lengths are matched within 2 mm + +rule matched length dram traces + let e1 (type(@, net)) && (@.a.group == "dram_data_0") + let e2 e1 + assert abs(netlen(e1) - netlen(e2)) < 2 mm + +# Example 3: check if isolation gap is maintained between any HV and LV nets +# (Lazy: assume any copper is part of a network, compare net-to-net only) +# +# hv is the list of high voltage nets +# lv is a list of non-hv networks +# + +rule isolation gap 1 + let hv (type(@, net)) && (@.a.high_voltage) + let lv (type(@, net)) && !(@.a.high_voltage) + assert !is_closer(lv, hv, 4 mm) + +# Example 4: check if isolation gap is maintained between any HV and LV nets +# (Proper way: do not forget about copper not part of any network!) +# +# hv is the list of high voltage nets +# hvo is a list of all objects found in hv +# cp is a list of all copper object +# There are two iterators in the assert: cp (all copper objects) and hv. +# For each hv and cp pair: +# - lcomplement returns a cp object if the cp object is not in hv (i.e. +# the object is low voltage); else the return value is empty and is_closer +# returns invalid which is not a violation +# - hvo is required because cp is an object while hv is a list of nets +# (so cp is never on the hv list) +# - if there was a valid (low voltage) cp object found, + +rule isolation gap 2 + let hv (type(@, net)) && (@.a.high_voltage) + let hvo lobjs(hv) + let cp (type(@, copper)) + assert !is_closer(lcomplement(cp, hvo), hv, 4 mm) Index: trunk/doc/developer/ddrc/proposal1.txt =================================================================== --- trunk/doc/developer/ddrc/proposal1.txt (nonexistent) +++ trunk/doc/developer/ddrc/proposal1.txt (revision 5594) @@ -0,0 +1,242 @@ +Dynamic DRC proposal 1: a Declarative DRC language. + +P0 A DRC program is an unordered list of rules. Rules are evaluated and + violations reported. The advantage of a declarative language is that + intermediate results can be cached and reused. + +P1 The language is intended to be human readable and human writable, but + the main goal is to let programs and scripts (e.g. netlisters) to + generate it. + +P2 A rule consists of three parts: + - the rule keyword; syntax: rule NAME + - build variables (lists) using search statements + - state assertions about those lists. + - comments, empty lines + +P3 Variables are named by the user and are local to the rule (TODO) + +P4 Lists are ordered. + +P5 A list is consists of zero or more objects. An object is: +P6 - the board +P7 - a layer +P8 - a board drawing primitive (line, arc, polygon, via, text) +P9 - an element primitive (element line, element arc(?), pin, pad, element name) +P10 - an element as a whole +P11 - a net +P61 - a 2D coordinate with or without layer information + +P12 Objects have named properties (or fields): +P13 - core attributes: for each object type a predefined set of key=value + pairs that always exist (e.g. thickness of a line, start angle of + an arc); these field names starts with "p." +P14 - user attributes: free-form key=value pairs optionally assigned by + the user; these field names start with "a." + +P15 Note: the language is case sensitive with keywords and builtins using + lowercase only. For better readability, in syntax description in this + document uppercase words are user chosen identifiers or fields. Whitespace + character sequences are usually treated as a single whitespace. (This + does not mean identifiers have to be uppercase in a program.) + + The syntax of a search statement is: + +P16 let LISTNAME EXPR + +P17 It creates a list called LISTNAME and evaluates expression EXPR to all + available objects and adds the objects that match EXPR to the list. Each + matching object is added only once. The particular order of objects on + the list is random. Object "matches EXPR" when the EXPR evaluated on + the object yields true. + +P18 The current object used in the iteration during the search is called + @. + +P19 An expression returns a value. A value can be: +P20 - an object +P21 - a list +P22 - scalar: a number or string (might be suffixed, like "42 mm") +P23 - void (empty, also known as false) + +P23 A value is considered true if: +P24 - it is an existing object +P25 - it is a non-empty list +P26 - it is a non-zero number or non-empty string +P69 - it is a valid coordinate + + An expression is one of: + + syntax meaning + ---------------------------------------------------------------- +P27 (EXPR) change precedence +P28 EXPR || EXPR logical OR (result: number) +P29 EXPR && EXPR logical AND (result: number) +P30 EXPR + EXPR add (number only) +P31 EXPR - EXPR subtract (number only) +P32 EXPR * EXPR multiply or ... (number only) +P32 EXPR / EXPR multiply or ... (number only) +P32 EXPR == EXPR the two values are equal +P33 EXPR != EXPR the two values are not equal +P71 EXPR ~ string regex match left EXPR using pattern right string +P34 EXPR > EXPR left EXPR is greater than right EXPR (number only) +P35 EXPR >= EXPR left EXPR is greater than or equal to right EXPR (number only) +P36 EXPR < EXPR left EXPR is less than right EXPR (number only) +P37 EXPR <= EXPR left EXPR is less than or equal to right EXPR (number only) +P38 !EXPR logical NOT (result: number, 0 or 1) +P39 FUNC(EXPR, EXPR, ...) call a function with 0 or more arguments +P40 EXPR.field evaluated to the value of an object field (see P45, P46) + + The syntax of an assertion is: + +P41 assert EXPR + +P42 If the EXPR in an assert evaluates to false, a DRC violation is generated. + +P43 If an assert EXPR is a list anywhere else than in a function argument, it is + evaluated for all valid members of the list (see P45, P46). For example + if there is a variable called FOO, which is a list of objects + (built using a search statement), expression + + FOO.p.thickness + + is evaluated as many times as many objects are on the list, and the + full assert is checked each case. If there is another similar list + called BAR, an expression: + + (FOO.p.thickness < BAR.p.thickness) + + will compare each possible pair of FOO and BAR objects. That is, if + FOO has 4 objects and BAR has 15 objects, that is 4*15 = 60 comparisons. + +P44 However, each list is iterated only once, even if it is referenced multiple + times in the same expression. For example, with the above lists: + + (FOO.p.clearance > 10 mil) && (FOO.p.thickness < BAR.p.thickness) + + the potential number of iterations is still 4*15, and not 4*4*15. In + practice the engine leverages lazy evaluation so if FOO.p.clearance + is smaller than 10 mil, the right size is not evaluated. See also: P45, P46. + +P45 A field reference is valid if the field exists. For example a line object + has a thickness attribute, thus the .p.thickness is valid, but a polygon + object does not have a thickness and .p.thickness on a polygon is invalid. + An user attribute reference (e.g. field .a.baz) is valid if the attribute + key exists in the given object. + +P46 Invalid fields are skipped in iterations. Thus if variable BLOBB is a list + that consists of 3 line, 2 arc and a layer objects, the following assert + will result in 2 comparisons only: + + (BLOBB.p.width >= 10 mm) + + (because only arc objects have valid .p.width field). + +P47. An invalid field in an expression is never considered an + error. In an assert statement it causes skipping an iteration. In a + search statement it evaluates to void. + +P48. A void value is never equal to anything. A void value is not equal + even to another void value. + +P49. Comments are lines starting with # + + + BUILTIN FUNCTIONS + +P70 list(LISTNAME) + Within an expression, a reference to a list may become an iterator and + refer to a single object. In case the expression needs the listm the + list() function protects LISTNAME from becoming an iterator. For + example llen(list(@)) is the number of all objects the design consists. + +P50 llen(EXPR) + Returns to the number of items of a list (an integer number >= 0). + +P51 lvalid(EXPR, field) + Returns a list of items on the list for which field is valid. + EXPR can be a list or an object. + +P52 lunion(EXPR1, EXPR2) + A new list is created; items of EXPR1 are copied to the new list in order. + Those items from EXPR2 that are not on the list already are appended, + keeping their order. The new list is returned. + + Both EXPR1 and EXPR2 can be either a list or an object. + + Note: order of arguments does matter (affects order of objects on the + resulting list). + +P53 lintersect(EXPR1, EXPR2) + A new list is created; items that are present on both EXPR1 and EXPR2 + are copied onto the new list. The new list is returned. + + Both EXPR1 and EXPR2 can be either a list or an object. + + Note 1: this function can be used as "is this object on the list" query: + list_intersection(LIST, OBJ) will result an empty list (which means false) + if OBJ is not on the list. + + Note 2: similarly, if both argument are objects, the result is false + if the two arguments are not the same object. + +P54 lcomplement(EXPR1, EXPR2) + Creates a new list with all items that are present in EXPR1 but not in + EXPR2. The new list is returned. + + Both EXPR1 and EXPR2 can be either a list or an object. + + +P55 ldiff(EXPR1, EXPR2) + Creates a new list with all items that are present either in EXPR1 or in + EXPR2 but not in both. The new list is returned. + + +P56 distance(EXPR1, EXPR2) + Calculates the shortest distance between two objects. Returns a number. + + Note: if any expression is a layer, the stack distance is calculated + (which will be 0 for now, as pcb-rnd doesn't yet know about layer thickness). + If the expression is a net, the whole shape of the net is used + (expensive! use is_closer() instead) + If the expression is the board, the operation is invalid (see P46). + +P57 is_closer(EXPR1, EXPR2, NUMBER) + Checks if EXPR1 and EXPR2 are closer to each-other than NUMBER. It uses + the classic bloat-and-find algorithm originally used by the classic DRC, + thus it is much cheaper than distance(EXPR1, EXPR2) < NUMBER. + +P58 netlen(EXPR) + Network length of EXRP1: sum of all non-overlapping trace/arc lengths that + make up a network; polygons are approximated with their average diameter + (TODO). If EXPR is an object, its length is returned. + +P59 netobjs(EXPR) + Creates and returns a list of objects consists of a net. + +P60 type(EXPR, TYPENAME) + EXPR is an object. Returns the object if it's type matches TYPENAME, else + returns void (a.k.a. false). This call is useful to decide whether an + object is of a specific type. TYPENAME is one of: + - drawing primitive type: arc, line, polygon, text, via, element + - element primitive type: element_line, element_name, pin, pad + - misc type: layer, net + - meta-type, or a group: + - copper: primitive that results in copper (arc, line, polygon, text (on copper), via, pin, pad) + - drilled: anything that drills the board (via, pin) + +P62 gridup(EXPR, NUM1, NUM2) + If expression is an object, return a list of coordinates that are on + the object, evenly spaced: +P63 - for lines and arcs, the points are evenly spaced on the centerlane with + a gap of NUM1, starting from both endpoints, having the corner case in + the middle; if NUM2 is 0, the gap at the middle may be larger than NUM1, + else it may be smaller than NUM1. +P64 - for polygons take a grid of NUM1*NUM2 spacing (NUM1 is always axis + aligned to X, NUM2 to Y). The offset of the grid is unspecified +P65 - element and text are ignored +P66 - a pad or pin is approximated with a polygon +P67 - for networks, iterate over all objects and append unique coordinates on + the resulting list +P68 There's no guarantee on the particular order of the list. + Index: trunk/doc/developer/ddrc/requirements.txt =================================================================== --- trunk/doc/developer/ddrc/requirements.txt (nonexistent) +++ trunk/doc/developer/ddrc/requirements.txt (revision 5594) @@ -0,0 +1,23 @@ +The Dynamic DRC should be able to solve at least these tasks: + - check start grounding + - require element placement on same layer + - specify element proximity to each other on same layer + - specify element proximity to the edge + - specify element proximity to network or other copper feature + on the same layer + - perform copper vs. copper checks + - minimal gap between an object or network and anything else + - minimal gap between high voltage and low voltage networks + - perform copper geometry checks + - detect minimal width (high current) + - detect poly hairpin + - number and length of stubs (hight freq) + - "via cage": a given network needs to be sorrounded by a set of gnd vias + - network related copper checks + - matched length lines (e.g. fast dram bus) + - balanced transmission line (distance between the tracks) + - match and/or limit number of vias + - limit layer usage + - require layer stackup properties, e.g. microstrip, stripline + - e.g. require ground poly on the next layer + - e.g. number of gaps in the ground poly the line jumps Index: trunk/doc/developer/hid_remote/Makefile =================================================================== --- trunk/doc/developer/hid_remote/Makefile (nonexistent) +++ trunk/doc/developer/hid_remote/Makefile (revision 5594) @@ -0,0 +1,9 @@ +proto_parse.svg: proto_parse.dot fixlab.sh + ./fixlab.sh < proto_parse.dot > .proto_parse.dot + dot -Tsvg .proto_parse.dot > proto_parse.svg + + +proto_parse.png: proto_parse.dot fixlab.sh + ./fixlab.sh < proto_parse.dot > .proto_parse.dot + dot -Tpng .proto_parse.dot > proto_parse.png + Index: trunk/doc/developer/hid_remote/fixlab.sh =================================================================== --- trunk/doc/developer/hid_remote/fixlab.sh (nonexistent) +++ trunk/doc/developer/hid_remote/fixlab.sh (revision 5594) @@ -0,0 +1,43 @@ +#!/bin/sh +awk ' +($2 == "->") { + + if (NF > 3) { + attr=$0 + if (!(attr ~ "[[]")) + attr = attr "[]" + } + else + attr = "[]" + + tmp = "lbl" (++lbl) + if (attr ~ "label") + extra_label="" + else + extra_label="label=\"\"" + + tmp_attr = attr + attr1=attr + attr2=attr + + if (extra_label == "") + sub("^[^[]*[[]", "[style=filled fillcolor=\"#fefefe\" shape=plaintext ", tmp_attr) + else { +# tmp_attr = "[fixedsize=true width=0 shape=plaintext " extra_label "]" + print $0 + next + } + + sub("^[^[]*[[]", "[", attr1) + sub("^[^[]*[[]", "[", attr2) + sub("label=\".*\"", "", attr1) + sub("label=\".*\"", "", attr2) + sub("[[]", "[arrowhead=none ", attr1) + + print tmp, tmp_attr + print $1, "->", tmp, attr1 + print tmp, "->", $3, attr2 + next +} +{ print $0 } +' \ No newline at end of file Property changes on: trunk/doc/developer/hid_remote/fixlab.sh ___________________________________________________________________ Added: svn:executable ## -0,0 +1 ## +* \ No newline at end of property Index: trunk/doc/developer/hid_remote/proto_high.html =================================================================== --- trunk/doc/developer/hid_remote/proto_high.html (nonexistent) +++ trunk/doc/developer/hid_remote/proto_high.html (revision 5594) @@ -0,0 +1,224 @@ + + +

remote HID protocol, high level

+ +

reference

+ +

ver(protver)

+Sends the protocol version the server will speak. If the client doesn't +support that version, it should break the connection. +

+Arguments: +

+ +

unit(abbrev)

+Sends the coordinate unit used in subsequent communication. This is not +necessarily the unit used for displaying values on the user interface, +but the unit used to interpret numeric coordinate values sent in commands. +

+Arguments: +

+ +

ready()

+Informs the client that the server is ready to start the session. The +client needs to answer with a Ready() message before the server proceeds. +

+Arguments: none. + + +

brddim(w h)

+Announce board dimensions. Some layers may extend beyond the board. +

+Arguments: +

+ +

inval(x1 x2 y1 y2)

+Invalidate a rectangular section of the screen; the client should redraw +this area. Clients implementing their own mechanism to keep track on +drawing are free to ignore these requests +

+Arguments: +

+ +

inval()

+Same as inval(x1 x2 y1 y2) but invalidates the whole screen. +

+Arguments: none + +

newly(name id flags groups)

+Inform the client that the next set of drawing commands are for a specific +layer. +

+Arguments: +

+

+Example: +

+newly(bottomassembly 16777226 ((bottom) (assy) (virtual)) -1)
+
+Creates the bottom assembly virtual layer with ID 16777226. It is not part of +any layer group and is called "bottomassembly". + +

setlg(group_id group_flags is_empty)

+Inform the client that the next set of drawing commands are for a specific +layer group. +

+Arguments: +

+ +

makeGC()

+Request the client to make a new graphical context. The client should +allocate a GC and return an integer ID using the MadeGC(ID) message. +The ID uniquely identifies the GC; it should be small positive integer +(between 0 and 31 for now). +

+Arguments: none + + + + +

delGC(ID)

+Inform the client that a given GC is not needed anymore. The server +will not reference the GC again and the GC can be destroyed (but graphics +drawn on the screen should not be affected). The ID may be reused by the +client in a subsequent madeGC() message). +

+Arguments: +

+ +

clr(gci colorstring)

+Change the color subsequent drawing commands of a given GC will use. +

+Arguments: +

+ +

cap(gci style)

+Set the line ending cap style. Note: the cap extends half-line-width beyond +the end coordinates, e.g. the end point of a line is the center of the round-cap +circle. +

+Arguments: +

+ + +

linwid(gci width)

+Sets line width (pen tip diameter). +

+Arguments: +

+ +

setxor(gci state)

+Sets whether to perform "xor-drawing" for subsequent drawing commands in +the selected GC. +

+Arguments: +

+ + +

line(gci x1 y1 x2 y2)

+Draw a line using the current GC. The line inherits line width, color +and cap style from the GC. +

+Arguments: +

+ +

rect(gci x1 y1 x2 y2 filled)

+Draw a rectangle. The rectangle inherits only color from the GC. +

+Arguments: +

+ + +

fcirc(gci cx cy r)

+Draw a filled circle. The circle inherits only color from the GC. +

+Arguments: +

+ +

poly(gci len ptlist)

+Draw a filled polygon. The polygon inherits only color from the GC. +

+Arguments: +

+ +

umask(m)

+"use mask" m. The server uses this message to make an announcement before it +starts drawing certain things. +

+Arguments: +

+ + + Index: trunk/doc/developer/hid_remote/proto_low.html =================================================================== --- trunk/doc/developer/hid_remote/proto_low.html (nonexistent) +++ trunk/doc/developer/hid_remote/proto_low.html (revision 5594) @@ -0,0 +1,146 @@ + + +

remote HID protocol, low level

+ +In this document bold words are tokens and italic words +are grammatic constructs. +

+The protocol is designed with the following goals in mind: +

+ + +

Tokens

+ +
token description +
( start a generic list +
) end a generic list +
{ start a binary list +
} end a binary list +
space element separator: space (ASCII dec 32) +
\n message separator: newline (ASCII dec 10) +
text-string short, alphanumeric string +
binary-string long and/or non-alnum string +
+ +

Grammar

+The communication is a pair of asynchronous message stream. The message +format is: +
+text-string generic-list \n
+or
+text-string binary-list \n
+or
+# comment \n
+
+

+where text-string is a command and generic-list is a list and holds +the arguments of. The command name can not start with a hash mark ('#') and +can not be empty. The list is the argument tree of the command. +

+As a special exception, a line may start with a hash mark ('#') to indicate +a comment. Characters up to the first newline are ignored. +

+Optional: a tolerant parser also accepts empty lines and whitespace before +a message. +

+The language has two type of lists: generic and binary. +A generic list is wrapped in parenthesis () and its children are: +

+A binary-list is wrapped in braces {} and its children are: + +

+Any list can be empty. There's no whitespace after the opening token and +before the closing token, so the empty generic-list and the empty binary-list +are written as, respectively: +

+()
+{}
+
+Subsequent fields of a list has a single space in between, for +separation (this is an intentional redundancy for a binary-list). +

+Note: a generic-list can host text and binary children, but a +binary list can not host only binary children. This means if a node +of the parse tree is a binary list, the subtree will contain only binary nodes. +

+A text-string contains only English alphanumeric characters (A..Z, a..z, +0..9), underscores (_), plus and minus signs (+, -) periods (.) and +the hash mark ('#') and is at most 16 characters long. +

+A binary string encodes the length of the payload in base64 (A..Z, a..z, +, /), +has a '=' for separator then the payload in binary format. For example +

+F=hello
+
+means the 5 characters long string "hello". The maximum size of the base64 +encoded length field is 5, thus the longest binary data that can be +packed in a single field is 1 gigabyte. + +

Examples

+ +

empty-argument messages

+
+hello()\n
+foo{}\n
+
+ +

single-argument messages

+Text and binary alternative for the same content: +
+hello(world)\n
+hello{F=world}\n
+
+ +

multi-argument messages

+Text and binary alternative for the same content: +
+print(hello world !)\n
+print{E=hello F=world B=!}\n
+
+ +Note: using space between list items; don't space +before the first or after the last argument. Always emit one space between +any two list items. + +

lists in list

+Text and binary alternatives for the same content: +
+line((14.55 3.1) (44.2 0) 5)\n
+line({F=14.55 D=3.1} (44.2 0) 5)\n
+line((14.55 3.1) {E=44.2 B=0} 5)\n
+line({F=14.55 D=3.1} {E=44.2 B=0} 5)\n
+line{{F=14.55 D=3.1} {E=44.2 B=0} B=5}\n
+
+The subtree assumed in this fictional message is two x;y coordinate pairs +and a line width. In other words the arguments of line is a list (start +point), another list (end point) and a scalar (width). +

+Since all data comply to the text-string token format, +the first, simplest format is recommended. The other 4 lines demonstrate all +other valid variants. +

+It is important to note that there are constraints (derived from +the grammar) on choosing which list items can be encoded in binary: +

+Thus if the 3rd argument, (width in this example), must be encoded as a +binary-string, it will turn it's parent, line's argument list +binary too, which in turn enforces all arguments to be binary. Index: trunk/doc/developer/hid_remote/proto_parse.dot =================================================================== --- trunk/doc/developer/hid_remote/proto_parse.dot (nonexistent) +++ trunk/doc/developer/hid_remote/proto_parse.dot (revision 5594) @@ -0,0 +1,84 @@ +digraph parse_state_macine { + + +MSG [label="MSG:\nmessage lead-in\nor\nbetween\nmessages" shape=box style=filled fillcolor=yellow] +COMMENT [label="COMMENT:\nskipping comment" shape=box style=filled fillcolor=yellow] +CMD [label="CMD:\nparsing command name" shape=box style=filled fillcolor=yellow] +TSTR [label="TSTR:\nparsing test string" shape=box style=filled fillcolor=yellow] +BSTR [label="BSTR:\nparsing bin string" shape=box style=filled fillcolor=yellow] +LIST [label="LIST:\nin list" shape=box style=filled fillcolor=yellow] +ERROR [label="ERROR:\nbad input" shape=box style=filled fillcolor=red] + +######## MSG + +init [shape="diamond" style=filled fillcolor=yellow] +init -> MSG + +msg_append [label="store 1st\ncommand char"] + +MSG -> COMMENT [label="input==#" color=blue] +MSG -> MSG [label="input==\\r\\n\\t\nspace" color=blue] +MSG -> ERROR [label="input==binary"] +MSG -> msg_append [label="input==text"] +msg_append -> CMD + +######## COMMENT + +COMMENT -> MSG [label="input==\\n" color=blue] +COMMENT -> COMMENT [color=blue] + + +######## CMD +cmd_list_new [label="create new list\nmake it arg tree\nroot and current"] +cmd_list_new -> LIST +cmd_append [label="append a character\nto command name"] +cmd_append -> CMD [label="command name length\nis less than 16"] +cmd_append -> ERROR [label="command name length\nis more than 16"] +CMD -> cmd_list_new [label="input==({"] +CMD -> ERROR [label="input==binary"] +CMD -> cmd_append [label="input==text"] + +######## LIST +got_msg [label="message fully parsed\nexecute message" style=filled fillcolor=cyan] +got_msg -> MSG +pop [label="pop:\ncurrent_list = current_list->parent"] +pop -> got_msg [label="input=\\n\nand\ncurrent_list == NULL\n(arg root closed)"] +pop -> ERROR [label="input!=\\n\nand\ncurrent_list == NULL\n(unbalanced parenthesis)"] +pop -> LIST +push [label="push:\create new list\nappend it as current's sibling\nmake it current"] +push->LIST +new_str [label="create a new bin or text string\nnode and append it to\nthe current list"] +new_str -> tstr_append [label="current is generic list"] +new_str -> bstr_append [label="current is binary list"] + +LIST -> pop [label="input==)}"] +LIST -> push [label="input==({"] +LIST -> LIST [label="input==space\n(ignore)"] +LIST -> ERROR [label="input!=\\n and current == NULL\n(unbalanced parenthesis)"] +LIST -> new_str [label="input==text"] + +######## TSTR +str_fin [label="finish current string\n"] +str_fin -> LIST +str_fin_pop [label="finish current string\n"] +str_fin_pop -> pop +tstr_append [label="append to current string\n"] +tstr_append -> ERROR [label="string length > 16"] +tstr_append -> TSTR +TSTR -> str_fin [label="input==space"] +TSTR -> str_fin_pop [label="input==)}"] +TSTR -> ERROR [label="input==binary"] +TSTR -> tstr_append [label="input==text"] + +######## BSTR +read_base64 [label="store next digit\nof string length"] +read_base64 -> BSTR +bstr_append -> BSTR +BSTR -> read_base64 [label="before the ="] +BSTR -> bstr_append [label="after the ="] +BSTR -> str_fin_pop [label="last char of the string"] + +######## ERR +ERROR -> ERROR [label="can't recover"] + +} Index: trunk/doc/developer/hid_remote/proto_parse.html =================================================================== --- trunk/doc/developer/hid_remote/proto_parse.html (nonexistent) +++ trunk/doc/developer/hid_remote/proto_parse.html (revision 5594) @@ -0,0 +1,38 @@ + + +Protocol parser state machine of the referece implementation: + +Legend: + +

Notes on the refernece implementation

+The reference implementation builds a tree of nodes for the arguments. +Each node is either a list or a text. A node has a pointer to its parent, its +first child and its next sibling. While parsing list-of-lists, the parser +keeps a current node. A new node is either added as the last sibling of +the current node (new argument on a list) or as the first +child of the current node (first argument of a new list when the list is +open). +

+When a list is closed, the parent of the current node becomes the +new current node. +

+When parsing a new message, the current node is NULL until the argument list +is open; the new current node also becomes the argument tree root. +If the argument tree root is closed, a newline shall follow, because that's +how a message is terminated. +

+The binary string part of the state machine has 2 more internal +states: +

+ + + \ No newline at end of file Index: trunk/doc/developer/hid_remote/proto_parse.svg =================================================================== --- trunk/doc/developer/hid_remote/proto_parse.svg (nonexistent) +++ trunk/doc/developer/hid_remote/proto_parse.svg (revision 5594) @@ -0,0 +1,597 @@ + + + + + + +parse_state_macine + + +MSG + +MSG: +message lead-in +or +between +messages + + +lbl2 + +input==# + + +MSG->lbl2 + + + +lbl3 + +input==\r\n\t +space + + +MSG->lbl3 + + + +lbl4 + +input==binary + + +MSG->lbl4 + + + +lbl5 + +input==text + + +MSG->lbl5 + + + +COMMENT + +COMMENT: +skipping comment + + +COMMENT->COMMENT + + + + +lbl7 + +input==\n + + +COMMENT->lbl7 + + + +CMD + +CMD: +parsing command name + + +lbl12 + +input==({ + + +CMD->lbl12 + + + +lbl13 + +input==binary + + +CMD->lbl13 + + + +lbl14 + +input==text + + +CMD->lbl14 + + + +TSTR + +TSTR: +parsing test string + + +lbl30 + +input==space + + +TSTR->lbl30 + + + +lbl31 + +input==)} + + +TSTR->lbl31 + + + +lbl32 + +input==binary + + +TSTR->lbl32 + + + +lbl33 + +input==text + + +TSTR->lbl33 + + + +BSTR + +BSTR: +parsing bin string + + +lbl36 + +before the = + + +BSTR->lbl36 + + + +lbl37 + +after the = + + +BSTR->lbl37 + + + +lbl38 + +last char of the string + + +BSTR->lbl38 + + + +LIST + +LIST: +in list + + +lbl21 + +input==)} + + +LIST->lbl21 + + + +lbl22 + +input==({ + + +LIST->lbl22 + + + +lbl23 + +input==space +(ignore) + + +LIST->lbl23 + + + +lbl24 + +input!=\n and current == NULL +(unbalanced parenthesis) + + +LIST->lbl24 + + + +lbl25 + +input==text + + +LIST->lbl25 + + + +ERROR + +ERROR: +bad input + + +lbl39 + +can't recover + + +ERROR->lbl39 + + + +init + +init + + +init->MSG + + + + +msg_append + +store 1st +command char + + +msg_append->CMD + + + + +lbl2->COMMENT + + + + +lbl3->MSG + + + + +lbl4->ERROR + + + + +lbl5->msg_append + + + + +lbl7->MSG + + + + +cmd_list_new + +create new list +make it arg tree +root and current + + +cmd_list_new->LIST + + + + +cmd_append + +append a character +to command name + + +lbl10 + +command name length +is less than 16 + + +cmd_append->lbl10 + + + +lbl11 + +command name length +is more than 16 + + +cmd_append->lbl11 + + + +lbl10->CMD + + + + +lbl11->ERROR + + + + +lbl12->cmd_list_new + + + + +lbl13->ERROR + + + + +lbl14->cmd_append + + + + +got_msg + +message fully parsed +execute message + + +got_msg->MSG + + + + +pop + +pop: +current_list = current_list->parent + + +pop->LIST + + + + +lbl16 + +input=\n +and +current_list == NULL +(arg root closed) + + +pop->lbl16 + + + +lbl17 + +input!=\n +and +current_list == NULL +(unbalanced parenthesis) + + +pop->lbl17 + + + +lbl16->got_msg + + + + +lbl17->ERROR + + + + +push + +push:create new list +append it as current's sibling +make it current + + +push->LIST + + + + +new_str + +create a new bin or text string +node and append it to +the current list + + +lbl19 + +current is generic list + + +new_str->lbl19 + + + +lbl20 + +current is binary list + + +new_str->lbl20 + + + +tstr_append + +append to current string + + +lbl19->tstr_append + + + + +tstr_append->TSTR + + + + +lbl28 + +string length > 16 + + +tstr_append->lbl28 + + + +bstr_append + +bstr_append + + +lbl20->bstr_append + + + + +bstr_append->BSTR + + + + +lbl21->pop + + + + +lbl22->push + + + + +lbl23->LIST + + + + +lbl24->ERROR + + + + +lbl25->new_str + + + + +str_fin + +finish current string + + +str_fin->LIST + + + + +str_fin_pop + +finish current string + + +str_fin_pop->pop + + + + +lbl28->ERROR + + + + +lbl30->str_fin + + + + +lbl31->str_fin_pop + + + + +lbl32->ERROR + + + + +lbl33->tstr_append + + + + +read_base64 + +store next digit +of string length + + +read_base64->BSTR + + + + +lbl36->read_base64 + + + + +lbl37->bstr_append + + + + +lbl38->str_fin_pop + + + + +lbl39->ERROR + + + + + Index: trunk/doc/developer/import.html =================================================================== --- trunk/doc/developer/import.html (nonexistent) +++ trunk/doc/developer/import.html (revision 5594) @@ -0,0 +1,64 @@ + + +

pcb-rnd hacking - how importers work

+ +

Introduction

+This document describes the common aspects of import code, be it an +import_ plugin or the load part of an io_plugin, importing a footprint, +loading a board or a netlist. + +

Data structures

+ +The board is stored in PCBType *. Some import code, like the one +that loads a design (an io plugin's ->parse_pcb function), gets the +target in an argument. (Other, non-import code usually operate on +the global variable that represents the current board: +PCBType *PCB.). +

+In either case, PCBType's most important field is PCBDataType *data, +which holds lists and vectors to store all objects on the board. When +the target is a buffer (e.g. io plugin's ->parse_element function), it's +a DataType *buf which also have a PCBDataType *data containing +the same data a board could. +

+A PCBDataType struct in turn has three sets of important fields: +

+Each layer is a LayerType structure. A layer has the following fields: + +

+Any code that needs to create objects should use the functions in create.[ch]. +The functions that operate layer-independently usually get a destination as +PCBDataType, so they can operate both on boards and buffers. A typical +example is PinTypePtr CreateNewVia(DataTypePtr Data, ...) that returns +NULL or the pointer to the new via that is already added to the corresponding list +of Data and in the rtree. +

+Layer object creation is done referencing the layer as LayerType *. A +typical example is LineTypePtr CreateDrawnLineOnLayer(LayerTypePtr Layer, ...) +which returns NULL on error or a pointer to the new line object created (inserted +in the layer's line list, added to the rtree). +

+Code should avoid manipulating the lists and rtree structures directly. + +
+
+Figure 1. simplified map of object related data structures +
+diamond: variable; rectangle: struct; round: struct field +
+ + +

Extra steps around creating a new board

+TODO: postproc, post*, other setup + + + + Index: trunk/doc/developer/indent.html =================================================================== --- trunk/doc/developer/indent.html (nonexistent) +++ trunk/doc/developer/indent.html (revision 5594) @@ -0,0 +1,15 @@ + + +

pcb-rnd - indentation

+ +As of r1022 all old code is converted using indent(1) with the following +command line: + +
+indent --line-length128 -brs -br -nce --tab-size2 -ut -npsl  -npcs -hnl $*
+
+

+Contributors are kindly asked to follow this style or run the above commandline +on their code before sending a patch or commiting to svn. + + Index: trunk/doc/developer/obj_func_naming.txt =================================================================== --- trunk/doc/developer/obj_func_naming.txt (nonexistent) +++ trunk/doc/developer/obj_func_naming.txt (revision 5594) @@ -0,0 +1,83 @@ +obj_* function naming conventions + + +High level (new/destroy): + + This is the recommended way of creating new objects. + + pcb_*_new(): + Calls pcb_*_alloc(), fills in fields from parameters and calls the post + processing (pcb_add_*_on_layer()) function as needed. Makes sanity checks + on the parameters and may fail upon that. + + pcb_*_new_*(): + Same as pcb_*_new(), but may do clever things so the object created may + not be 1:1 what was reqested or may not even be a new object (e.g. + overlapping line merging) + + pcb_element_*_new(): + same as pcb_*_new(), parent being an element + + pcb_*_destroy() + free all fields of an object and properly remove it from the parent + (including rtree removal) + +Low level (alloc/free): + + Use this in some special cases (like loading a file) when the extra checks + of a _new may interfere. + + pcb_*_alloc(): + allocate a new objects within a parent (as of now: layer). Allocates + the struct of a new objects with all fields clean and links the object + in the parent list. Returns a pointer to the object. NOTE: some post + processing may be needed after filling in the fields + (see also: pcb_add_*_on_layer()) + + pcb_element_*_alloc(): + same, but parent is an element - will be removed once elements are + generalized. + + pcb_*_free(): + free the struct memory (but not the fields!) of an object and remove + it from the parent list. + + pcb_add_*_on_layer(): + Postprocessing: call this after a new object is allocated and fields are + filled in. It mainly updates the rtree. + + pcb_*_copy(): + copy fields of a complex obj to a pre-allocated target obj + + +Accessors: + pcb_*_get_*(): + Return data that are not directly accessible as object struct fields but + require some sort of calculation + + pcb_*_set_*(): + Set object fields that require postprocessing because of side effects. + Use these instead of direct writes to the fields to get side effects + properly executed. + + pcb_*_change_*(): + Similar to pcb_*_set_*(), but instead of setting a field to a value + specified as a parameter, change the field to comply with some global + state, e.g. "change side" would move the object to the currently viewed + side. + +Trasformations: + pcb_*_move(): + move the object within its parent (x;y); it's often implemented as a + macro + + pcb_*_mirror(): + mirror the object within its parent (x;y) + + +Misc: + pcb_*_bbox(): + calculate and update the bounding box of an object + + pcb_*_rotate90() + Rotate the object by n*90 degrees Index: trunk/doc/developer/plugin_core_simple.html =================================================================== --- trunk/doc/developer/plugin_core_simple.html (nonexistent) +++ trunk/doc/developer/plugin_core_simple.html (revision 5594) @@ -0,0 +1,59 @@ + + +

pcb-rnd hacking - simple core plugins

+ +

Introduction

+ +

Setting up a new core plugin

+ + + + Index: trunk/doc/developer/plugin_naming.html =================================================================== --- trunk/doc/developer/plugin_naming.html (nonexistent) +++ trunk/doc/developer/plugin_naming.html (revision 5594) @@ -0,0 +1,12 @@ + + +

pcb-rnd hacking - plugin naming conventions

+ + + Index: trunk/doc/developer/releasing.txt =================================================================== --- trunk/doc/developer/releasing.txt (nonexistent) +++ trunk/doc/developer/releasing.txt (revision 5594) @@ -0,0 +1,11 @@ +release check list + +0. test compile and test run a clean checkout on a clean system + configure with --debug --all=buildin, then without +1. check next version number and previous revision in tags/ +2. update the changelog +3. rewrite the release notes +4. modify version number in scconfig +5. update changelog in debian/ +6. commit trunk +7. svn tag using URLs Index: trunk/doc/developer/renames =================================================================== --- trunk/doc/developer/renames (nonexistent) +++ trunk/doc/developer/renames (revision 5594) @@ -0,0 +1,1516 @@ +Name differences between mainline -> pcb_rnd +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +#types: + +PCBTypePtr -> pcb_board_t * +PCBType -> pcb_board_t +DataTypePtr -> pcb_data_t * +DataType -> pcb_data_t +LayerGroupTypePtr -> pcb_layer_group_t * +LayerGroupType -> pcb_layer_group_t +LayerTypePtr -> pcb_layer_t * +LayerType -> pcb_layer_t +BufferTypePtr -> pcb_buffer_t * +BufferType -> pcb_buffer_t +NetTypePtr -> pcb_net_t * +NetType -> pcb_net_t +ConnectionTypePtr -> pcb_connection_t * +ConnectionType -> pcb_connection_t +BoxTypePtr -> pcb_box_t * +BoxType -> pcb_box_t +BoxListTypePtr -> pcb_box_list_t * +BoxListType -> pcb_box_list_t +FontTypePtr -> pcb_font_t * +FontType -> pcb_font_t +LineTypePtr -> pcb_line_t * +LineType -> pcb_line_t +AttachedObjectTypePtr -> pcb_attached_obj_t * +AttachedObjectType -> pcb_attached_obj_t +AttachedLineTypePtr -> pcb_attached_line_t * +AttachedLineType -> pcb_attached_line_t +CrosshairTypePtr -> pcb_crosshair_t * +CrosshairType -> pcb_crosshair_t +MarkTypePtr -> pcb_mark_t * +MarkType -> pcb_mark_t +ArcTypePtr -> pcb_arc_t * +ArcType -> pcb_arc_t +PointTypePtr -> pcb_point_t * +PointType -> pcb_point_t +RatTypePtr -> pcb_rat_t * +RatType -> pcb_rat_t +PolygonTypePtr -> pcb_polygon_t * +PolygonType -> pcb_polygon_t +PadTypePtr -> pcb_pad_t * +PadType -> pcb_pad_t +PinTypeType -> pcb_pin_t * +PinType -> pcb_pin_t +ElementTypeHandle -> pcb_element_t ** +ElementTypePtr -> pcb_element_t * +ElementType -> pcb_element_t +TextTypePtr -> pcb_text_t * +TextType -> pcb_text_t +AttributeListTypePtr -> pcb_attribute_list_t * +AttributeListType -> pcb_attribute_list_t +AttributeTypePtr -> pcb_attribute_t * +AttributeType -> pcb_attribute_t +OutputTypePtr -> pcb_output_t * +OutputType -> pcb_output_t +DrcViolationTypePtr -> pcb_drc_violation_t * +DrcViolationType -> pcb_drc_violation_t +FlagBitsTypePtr -> pcb_flag_bits_t * +FlagBitsType -> pcb_flag_bits_t +FlagTypePtr -> pcb_flag_t * +FlagType -> pcb_flag_t +SymbolTypePtr -> pcb_symbol_t * +SymbolType -> pcb_symbol_t +FunctionID -> pcb_function_id_t +EndCapStyle -> pcb_cap_style_t +hidval -> pcb_hidval_t +HID_Action -> pcb_hid_action_t +PCBWatchFlags -> pcb_watch_flags_t +HID_DRC_GUI -> pcb_hid_drc_gui_t +HID -> pcb_hid_t +hid_gc_struct -> hid_gc_s +hidGC -> pcb_hid_gc_t +HID_Attr_Val -> pcb_hid_attr_val_t +HID_Attribute -> pcb_hid_attribute_t +HID_AttrNode -> pcb_hid_attr_node_t +LibraryEntryTypePtr -> pcb_lib_entry_t * +LibraryEntryType -> pcb_lib_entry_t +LibraryMenuTypePtr -> pcb_lib_menu_t * +LibraryMenuType -> pcb_lib_menu_t +LibraryTypePtr -> pcb_lib_t * +LibraryType -> pcb_lib_t +UnitList -> pcb_unit_list_t +unitflags -> pcb_unit_flags_e +UnitList -> pcb_unit_list_t +NetListTypePtr -> pcb_netlist_t * +NetListType -> pcb_netlist_t +NetListListTypePtr -> pcb_netlist_list_t * +NetListListType -> pcb_netlist_list_t +AnyObjectTypePtr -> pcb_any_obj_t * +AnyObjectType -> pcb_any_obj_t +AnyLineObjectTypePtr -> pcb_any_line_t * +AnyLineObjectType -> pcb_any_line_t +AttachedLineTypePtr -> pcb_attached_line_t +AttachedLineType -> pcb_attached_line_t * +Vector -> pcb_vector_t +vertex -> pcb_vertex_t +CVCList -> pcb_cvc_list_t +VNODE -> pcb_vnode_t +PLINE -> pcb_pline_t +POLYAREA -> pcb_polyarea_t +PolygonBooleanOperation -> pcb_poly_bool_op_e +RubberbandType -> pcb_rubberband_t +Unit -> pcb_unit_t +Increments -> pcb_increments_t +Angle -> pcb_angle_t +Coord -> pcb_coord_t +RouteStyleTypePtr -> pcb_route_style_t * +RouteStyleType -> pcb_route_style_t +heap_t -> pcb_heap_t +cost_t -> pcb_cost_t + +# functions: +EventMoveCrosshair -> pcb_event_move_crosshair +AdjustAttachedObjects -> pcb_adjust_attached_objects + +warpNoWhere -> pcb_warp_nowhere +get_style_size -> pcb_get_style_size +NotifyLine -> pcb_notify_line +NotifyBlock -> pcb_notify_block +NotifyMode -> pcb_notify_mode +ClearWarnings -> pcb_clear_warnings +ReleaseMode -> pcb_release_mode +AFAIL -> PCB_AFAIL +ACTION_ARG -> PCB_ACTION_ARG +AttributeGetFromList -> pcb_attribute_get +AttributePutToList -> pcb_attribute_put +AttributeRemoveFromList -> pcb_attribute_remove +FreeAttributeListMemory -> pcb_attribute_free +AttributeGet -> pcb_attrib_get +AttributePut -> pcb_attrib_put +AttributeRemove -> pcb_attrib_remove +FreePCBMemory -> pcb_board_free +CreateNewPCB_ -> pcb_board_new_ +CreateNewPCB -> pcb_board_new +CreateNewPCBPost -> pcb_board_new_postproc +CountHoles -> pcb_board_count_holes +SWAP_X -> PCB_SWAP_X +SWAP_Y -> PCB_SWAP_Y +ROTATEBOX_CW -> PCB_BOX_ROTATE_CW +ROTATEBOX_TO_NORTH -> PCB_BOX_ROTATE_TO_NORTH +ROTATEBOX_FROM_NORTH -> PCB_BOX_ROTATE_FROM_NORTH +CENTER_X -> PCB_BOX_CENTER_X +CENTER_Y -> PCB_BOX_CENTER_Y +MOVE_BOX_LOWLEVEL -> PCB_BOX_MOVE_LOWLEVEL +point_in_box -> pcb_point_in_box +point_in_closed_box -> pcb_point_in_closed_box +box_is_good -> pcb_box_is_good +box_intersect -> pcb_box_intersect +closest_pcb_point_in_box -> pcb_closest_pcb_point_in_box +box_in_box -> pcb_box_in_box +clip_box -> pcb_clip_box +shrink_box -> pcb_shrink_box +bloat_box -> pcb_bloat_box +box_center -> pcb_box_center +box_corner -> pcb_box_corner +point_box -> pcb_point_box +close_box -> pcb_close_box +dist2_to_box -> pcb_dist2_to_box +GetBoxMemory -> pcb_box_new +FreeBoxListMemory -> pcb_box_free +SetPointBoundingBox -> pcb_set_point_bounding_box +SwapBuffer -> pcb_swap_buffer +SetBufferBoundingBox -> pcb_set_buffer_bbox +ClearBuffer -> pcb_buffer_clear +pcb_swap_buffer -> pcb_buffer_swap +pcb_buffer_set_bbox -> +AddSelectedToBuffer -> pcb_buffer_add_selected +LoadLayoutToBuffer -> pcb_buffer_load_layout +RotateBuffer -> pcb_buffer_rotate +SelectPasteBuffer -> pcb_buffer_select_paste +MirrorBuffer -> pcb_buffer_mirror +InitBuffers -> pcb_init_buffers +UninitBuffers -> pcb_uninit_buffers +MoveObjectToBuffer -> pcb_move_obj_to_buffer +CopyObjectToBuffer -> pcb_copy_obj_to_buffer +LoadFootprint -> pcb_load_footprint +CreateNewBuffer -> pcb_buffer_new +PASTEBUFFER -> PCB_PASTEBUFFER +QuitApplication -> pcb_quit_app +GetInfoString -> pcb_get_infostr +ChangeLayoutName -> pcb_board_change_name +ChangeLayerName -> pcb_layer_change_name +ChangeSelectedSize -> pcb_chg_selected_size +ChangeSelectedClearSize -> pcb_chg_selected_clear_size +ChangeSelected2ndSize -> pcb_chg_selected_2nd_size +ChangeSelectedMaskSize -> pcb_chg_selected_mask_size +ChangeSelectedJoin -> pcb_chg_selected_join +SetSelectedJoin -> pcb_set_selected_join +ClrSelectedJoin -> pcb_clr_selected_join +ChangeSelectedNonetlist -> pcb_chg_selected_nonetlist +ChangeSelectedSquare -> pcb_chg_selected_square +SetSelectedSquare -> pcb_set_selected_square +ClrSelectedSquare -> pcb_clr_selected_square +ChangeSelectedThermals -> pcb_chg_selected_thermals +ChangeSelectedHole -> pcb_chg_selected_hole +ChangeSelectedPaste -> pcb_chg_selected_paste +ChangeSelectedOctagon -> pcb_chg_selected_octagon +SetSelectedOctagon -> pcb_set_selected_octagon +ClrSelectedOctagon -> pcb_clr_selected_octagon +ChangeObjectSize -> pcb_chg_obj_size +ChangeObject1stSize -> pcb_chg_obj_1st_size +ChangeObjectThermal -> pcb_chg_obj_thermal +ChangeObjectClearSize -> pcb_chg_obj_clear_size +ChangeObject2ndSize -> pcb_chg_obj_2nd_size +ChangeObjectMaskSize -> pcb_chg_obj_mask_size +ChangeObjectJoin -> pcb_chg_obj_join +SetObjectJoin -> pcb_set_obj_join +ClrObjectJoin -> pcb_clr_obj_join +ChangeObjectNonetlist -> pcb_chg_obj_nonetlist +ChangeObjectSquare -> pcb_chg_obj_square +SetObjectSquare -> pcb_set_obj_square +ClrObjectSquare -> pcb_clr_obj_square +ChangeObjectOctagon -> pcb_chg_obj_octagon +SetObjectOctagon -> pcb_set_obj_octagon +ClrObjectOctagon -> pcb_clr_obj_octagon +ChangeObjectName -> pcb_chg_obj_name +QueryInputAndChangeObjectName -> pcb_chg_obj_name_query +ChangeObjectPinnum -> pcb_chg_obj_pinnum +ChangeObjectRadius -> pcb_chg_obj_radius +ChangeObjectAngle -> pcb_chg_obj_angle +ChangeSelectedAngle -> pcb_chg_selected_angle +ChangeSelectedRadius -> pcb_chg_selected_radius +QueryInputAndpcb_chg_obj_name -> pcb_chg_obj_name_query +ChangePCBSize -> pcb_board_resize +ClipLine -> pcb_line_clip +GetWorkingDirectory -> pcb_get_wd +tempfile_name_new -> pcb_tempfile_name_new +tempfile_unlink -> pcb_tempfile_unlink +lrealpath -> pcb_lrealpath +get_user_name -> pcb_get_user_name +CopyPastebufferToLayout -> pcb_buffer_copy_to_layout +CopyObject -> pcb_copy_obj +GridFit -> pcb_grid_fit +notify_crosshair_change -> pcb_notify_crosshair_change +notify_mark_change -> pcb_notify_mark_change +HideCrosshair -> pcb_crosshair_hide +RestoreCrosshair -> pcb_crosshair_restore +DrawAttached -> pcb_draw_attached +DrawMark -> pcb_draw_mark +MoveCrosshairRelative -> pcb_crosshair_move_relative +MoveCrosshairAbsolute -> pcb_crosshair_move_absolute +SetCrosshairRange -> pcb_crosshair_set_range +InitCrosshair -> pcb_crosshair_init +DestroyCrosshair -> pcb_crosshair_uninit +FitCrosshairIntoGrid -> pcb_crosshair_grid_fit +CenterDisplay -> pcb_center_display +FreeDataMemory -> pcb_data_free +IsDataEmpty -> pcb_data_is_empty +GetDataBoundingBox -> pcb_data_bbox +Draw -> pcb_draw +Redraw -> pcb_redraw +DrawObject -> pcb_draw_obj +DrawLayer -> pcb_draw_layer +EraseObject -> pcb_erase_obj +LightenColor -> pcb_lighten_color +Message -> pcb_message +OpenErrorpcb_messag -> pcb_open_error_message +PopenErrorpcb_message -> pcb_popen_error_message +OpendirErrorpcb_message -> pcb_opendir_error_message +ChdirErrorpcb_message -> ocb_chdir_error_message +OpenErrorpcb_message -> pcb_open_error_message +CatchSignal -> pcb_catch_signal +events_init -> pcb_events_init +events_uninit -> pcb_events_uninit +event_bind -> pcb_event_bind +event_unbind -> pcb_event_unbind +event_unbind_cookie -> pcb_event_unbind_cookie +event_unbind_allcookie -> pcb_event_unbind_allcookie +event -> pcb_event +LineLineIntersect -> pcb_intersect_line_line +LineArcIntersect -> pcb_intersect_line_arc +PinLineIntersect -> pcb_intersect_line_pin +LinePadIntersect -> pcb_intersect_line_pad +ArcPadIntersect -> pcb_intersect_arc_pad +IsPolygonInPolygon -> pcb_is_poly_in_poly +LookupElementConnections -> pcb_lookup_element_conns +LookupConnectionsToAllElements -> pcb_lookup_conns_to_all_elements +LookupConnection -> pcb_lookup_conn +LookupConnectionByPin -> pcb_lookup_conn_by_pin +LookupUnusedPins -> pcb_lookup_unused_pins +ResetFoundLinesAndPolygons -> pcb_reset_found_lines_polys +ResetFoundPinsViasAndPads -> pcb_reset_found_pins_vias_pads +ResetConnections -> pcb_reset_conns +InitConnectionLookup -> pcb_conn_lookup_init +InitComponentLookup -> pcb_component_lookup_init +InitLayoutLookup -> pcb_layout_lookup_init +FreeConnectionLookupMemory -> pcb_conn_lookup_uninit +FreeComponentLookupMemory -> pcb_component_lookup_uninit +FreeLayoutLookupMemory -> pcb_layout_lookup_uninit +RatFindHook -> pcb_rat_find_hook +SaveFindFlag -> pcb_save_find_flag +RestoreFindFlag -> pcb_restore_find_flag +DRCAll -> pcb_drc_all +IsLineInPolygon -> pcb_is_line_in_poly +IsArcInPolygon -> pcb_is_arc_in_poly +IsPadInPolygon -> pcb_is_pad_in_poly +ClearFlagOnPinsViasAndPads -> pcb_clear_flag_on_pins_vias_pads +ClearFlagOnLinesAndPolygons -> pcb_clear_flag_on_lines_polys +ClearFlagOnAllObjects -> pcb_clear_flag_on_all_objs +MakeFlags -> pcb_flag_make +OldFlags -> pcb_flag_old +AddFlags -> pcb_flag_add +MaskFlags -> pcb_flag_mask +EraseFlags -> pcb_flag_erase +NoFlags -> pcb_no_flags +mem_any_set -> pcb_mem_any_set +SET_FLAG -> PCB_FLAG_SET +CLEAR_FLAG -> PCB_FLAG_CLEAR +TEST_FLAG -> PCB_FLAG_TEST +TOGGLE_FLAG -> PCB_FLAG_TOGGLE +ASSIGN_FLAG -> PCB_FLAG_ASSIGN +TEST_FLAGS -> PCB_FLAGS_TEST +CHANGE_FLAG -> PCB_FLAG_CHANGE +FLAGS_EQUAL -> PCB_FLAG_EQ +THERMFLAG -> PCB_FLAG_THERM +TEST_THERM -> PCB_FLAG_THERM_TEST +GET_THERM -> PCB_FLAG_THERM_GET +CLEAR_THERM -> PCB_FLAG_THERM_CLEAR +ASSIGN_THERM -> PCB_FLAG_THERM_ASSIGN +GET_SQUARE -> PCB_FLAG_SQUARE_GET +CLEAR_SQUARE -> PCB_FLAG_SQUARE_CLEAR +ASSIGN_SQUARE -> PCB_FLAG_SQUARE_ASSIGN +GET_INTCONN -> PCB_FLAG_INTCONN_GET +TEST_ANY_THERMS -> PCB_FLAG_THERM_TEST_ANY +common_string_to_flags -> pcb_strflg_common_s2f +common_flags_to_string -> pcb_strflg_common_f2s +uninit_strflags_buf -> pcb_strflg_uninit_buf +uninit_strflags_layerlist -> pcb_strflg_uninit_layerlist +pcbflags_to_string -> pcb_strflg_board_f2s +string_to_pcbflags -> pcb_strflg_board_s2f +string_to_flags -> pcb_strflg_s2f +flags_to_string -> pcb_strflg_f2s +CreateDefaultFont -> pcb_font_create_default +SetFontInfo -> pcb_font_set_info +CreateNewLineInSymbol -> pcb_font_new_line_in_sym +leaky_init -> pcb_leaky_init +leaky_uninit -> pcb_leaky_uninit +leaky_malloc -> pcb_leaky_malloc +leaky_calloc -> pcb_leaky_calloc +leaky_realloc -> pcb_leaky_realloc +leaky_strdup -> pcb_leaky_strdup +funchash_get -> pcb_funchash_get +funchash_set -> pcb_funchash_set +funchash_set_table -> pcb_funchash_set_table +funchash_remove_cookie -> pcb_funchash_remove_cookie +funchash_init -> pcb_funchash_init +funchash_uninit -> pcb_funchash_uninit +heap_create -> pcb_heap_create +heap_destroy -> pcb_heap_destroy +heap_free -> pcb_heap_free +heap_insert -> pcb_heap_insert +heap_remove_smallest -> pcb_heap_remove_smallest +heap_replace -> pcb_heap_replace +heap_is_empty -> pcb_heap_is_empty +heap_size -> pcb_heap_size +hid_register_action -> pcb_hid_register_action +hid_register_actions -> pcb_hid_register_actions +REGISTER_ACTIONS -> PCB_REGISTER_ACTIONS +HIDCONCAT -> PCB_HIDCONCAT +hid_expose_callback -> pcb_hid_expose_callback +hid_actions_init -> pcb_hid_actions_init +hid_actions_uninit -> pcb_hid_actions_uninit +REGISTER_ATTRIBUTES -> PCB_REGISTER_ATTRIBUTES +print_actions -> pcb_print_actions +dump_actions -> pcb_dump_actions +hid_find_action -> pcb_hid_find_action +hid_remove_actions -> pcb_hid_remove_actions +hid_remove_action -> pcb_hid_remove_action +hid_remove_actions_by_cookie -> pcb_hid_remove_actions_by_cookie +hid_action -> pcb_hid_action +hid_actionl -> pcb_hid_actionl +hid_actionv -> pcb_hid_actionv +hid_actionv_ -> pcb_hid_actionv_ +hid_parse_command -> pcb_hid_parse_command +hid_parse_actions -> pcb_hid_parse_actions +hid_register_attributes -> pcb_hid_register_attributes +hid_remove_attributes_by_cookie -> pcb_hid_remove_attributes_by_cookie +hid_attributes_uninit -> pcb_hid_attributes_uninit +hid_usage -> pcb_hid_usage +hid_usage_option -> pcb_hid_usage_option +hid_cfg_create_menu -> pcb_hid_cfg_create_menu +hid_cfg_remove_menu -> pcb_hid_cfg_remove_menu +hid_cfg_load -> pcb_hid_cfg_load +hid_cfg_load_lht -> pcb_hid_cfg_load_lht +hid_cfg_load_str -> pcb_hid_cfg_load_str +hid_cfg_get_menu -> pcb_hid_cfg_get_menu +hid_cfg_get_menu_at -> pcb_hid_cfg_get_menu_at +hid_cfg_menu_field_path -> pcb_hid_cfg_menu_field_path +hid_cfg_menu_field_str -> pcb_hid_cfg_menu_field_str +hid_cfg_menu_field -> pcb_hid_cfg_menu_field +hid_cfg_has_submenus -> pcb_hid_cfg_has_submenus +hid_cfg_create_hash_node -> pcb_hid_cfg_create_hash_node +hid_cfg_extend_hash_nodev -> pcb_hid_cfg_extend_hash_nodev +hid_cfg_extend_hash_node -> pcb_hid_cfg_extend_hash_node +hid_cfg_dfs -> pcb_hid_cfg_dfs +hid_cfg_error -> pcb_hid_cfg_error +hid_cfg_action -> pcb_hid_cfg_action +hid_cfg_keys_init -> pcb_hid_cfg_keys_init +hid_cfg_keys_uninit -> pcb_hid_cfg_keys_uninit +hid_cfg_keys_add_under -> pcb_hid_cfg_keys_add_under +hid_cfg_keys_add_by_desc -> pcb_hid_cfg_keys_add_by_desc +hid_cfg_keys_add_by_strdesc -> pcb_hid_cfg_keys_add_by_strdesc +hid_cfg_keys_gen_accel -> pcb_hid_cfg_keys_gen_accel +hid_cfg_keys_input -> pcb_hid_cfg_keys_input +hid_cfg_keys_action -> pcb_hid_cfg_keys_action +hid_cache_color -> pcb_hid_cache_color +common_fill_pcb_polygon -> pcb_dhlp_fill_pcb_polygon +common_thindraw_pcb_polygon -> pcb_dhlp_thindraw_pcb_polygon +common_fill_pcb_pad -> pcb_dhlp_fill_pcb_pad +common_thindraw_pcb_pad -> pcb_dhlp_thindraw_pcb_pad +common_fill_pcb_pv -> pcb_dhlp_fill_pcb_pv +common_thindraw_pcb_pv -> pcb_dhlp_thindraw_pcb_pv +common_draw_helpers_init -> pcb_dhlp_draw_helpers_init +hid_get_extents -> pcb_hid_get_extents +hid_save_and_show_layer_ons -> pcb_hid_save_and_show_layer_ons +hid_restore_layer_ons -> pcb_hid_restore_layer_ons +hid_get_flag -> pcb_hid_get_flag +derive_default_filename -> pcb_derive_default_filename +layer_type_to_file_name -> pcb_layer_type_to_file_name +hid_init -> pcb_hid_init +hid_uninit -> pcb_hid_uninit +hid_find_gui -> pcb_hid_find_gui +hid_find_printer -> pcb_hid_find_printer +hid_find_exporter -> pcb_hid_find_exporter +hid_enumerate -> pcb_hid_enumerate +hid_parse_command_line -> pcb_hid_parse_command_line +hid_register_hid -> pcb_hid_register_hid +hid_remove_hid -> pcb_hid_remove_hid +common_nogui_init -> pcb_hid_nogui_init +hid_nogui_get_hid -> pcb_hid_nogui_get_hid +InsertPointIntoObject -> pcb_insert_point_in_object +AdjustInsertPoint -> pcb_adjust_insert_point +ComputeIntersectionArea -> pcb_intersect_box_box +ComputeUnionArea -> pcb_union_box_box +GetLibraryMenuMemory -> pcb_lib_menu_new +GetLibraryEntryMemory -> pcb_lib_entry_new +FreeLibraryMemory -> pcb_lib_free +DeleteLibraryMenuMemory -> pcb_lib_menu_free +CreateNewNet -> pcb_lib_net_new +CreateNewConnection -> pcb_lib_conn_new +ENTRIES -> PCB_ENTRIES +UNKNOWN -> PCB_UNKNOWN +NSTRCMP -> PCB_NSTRCMP +EMPTY -> PCB_EMPTY +EMPTY_STRING_P -> PCB_EMPTY_STRING_P +XOR -> PCB_XOR +SQUARE -> PCB_SQUARE +OBJECT_ID -> PCB_OBJECT_ID +FRONT -> PCB_FRONT +ON_SIDE -> PCB_ON_SIDE +TO_RADIANS -> PCB_TO_RADIANS +MAKEMIN -> PCB_MAKE_MIN +MAKEMAX -> PCB_MAKE_MAX +SGNZ -> PCB_SGNZ +SWAP_SIGN_X -> PCB_SWAP_SIGN_X +SWAP_SIGN_Y -> PCB_SWAP_SIGN_Y +Distance2 -> pcb_distance2 +Distance -> pcb_distance +GetValue -> pcb_get_value +GetValueEx -> pcb_get_value_ex +GetNum -> pcb_get_num +Concat -> pcb_concat +StripWhiteSpaceAndDup -> pcb_strdup_strip_wspace +MoveLayer -> pcb_layer_move +MOVE -> PCB_MOVE +MoveObject -> pcb_move_obj +MoveObjectToLayer -> pcb_move_obj_to_layer +MoveObjectAndRubberband -> pcb_move_obj_and_rubberband +MoveSelectedObjectsToLayer -> pcb_move_selected_objs_to_layer +GetNetMemory -> pcb_net_new +GetNetListMemory -> pcb_netlist_new +FreeNetListListMemory -> pcb_netlist_list_free +FreeNetListMemory -> pcb_netlist_free +FreeNetMemory -> pcb_net_free +NETLIST_LOOP -> PCB_NETLIST_LOOP +NET_LOOP -> PCB_NET_LOOP +GetArcMemory -> pcb_arc_new +GetElementArcMemory -> pcb_element_arc_new +RemoveFreeArc -> pcb_arc_free +GetElementMemory -> pcb_element_new +RemoveFreeElement -> pcb_element_free +FreeElementMemory -> pcb_element_free_fields +GetElementLineMemory -> pcb_element_line_new +GetLineMemory -> pcb_line_new +RemoveFreeLine -> pcb_line_free +CreateNewLineOnLayer -> pcb_line_new_on_layer +CreateDrawnLineOnLayer -> pcb_line_new_on_layer_merge +GetPadMemory -> pcb_pad_new +RemoveFreePad -> pcb_pad_free +CreateNewPad -> pcb_pad_new_in_element +SetPadBoundingBox -> pcb_pad_bbox +GetViaMemory -> pcb_via_new +RemoveFreeVia -> pcb_via_free +GetPinMemory -> pcb_pin_new +RemoveFreePin -> pcb_pin_free +CreateNewVia -> pcb_via_new_on_board +CreateNewPin -> pcb_pin_new_in_element +SetPinBoundingBox -> pcb_pin_bbox +GetPolygonMemory -> pcb_poly_alloc +RemoveFreePolygon -> pcb_poly_free +GetPointMemoryInPolygon -> pcb_poly_point_alloc +GetHoleIndexMemoryInPolygon -> pcb_poly_holeidx_new +FreePolygonMemory -> pcb_poly_free_fields +SetPolygonBoundingBox -> pcb_poly_bbox +CreateNewPolygonFromRectangle -> pcb_poly_new_from_rectangle +CreateNewPolygon -> pcb_poly_new +CreateNewPointInPolygon -> pcb_poly_point_new +CreateNewHoleInPolygon -> pcb_poly_hole_new +RemovePolygon -> pcb_poly_remove +GetRatMemory -> pcb_rat_alloc +RemoveFreeRat -> pcb_rat_free +CreateNewRat -> pcb_rat_new +DeleteRats -> pcb_rats_delete +GetTextMemory -> pcb_text_alloc +RemoveFreeText -> pcb_text_free +CreateNewText -> pcb_text_new +pcb_arc_new -> pcb_arc_alloc +CreateNewArcOnLayer -> pcb_arc_new +RemoveArc -> pcb_arc_destroy +pcb_element_arc_new -> pcb_element_arc_alloc +pcb_element_new -> pcb_element_alloc +pcb_element_free_fields -> pcb_element_destroy +pcb_line_new -> pcb_line_alloc +pcb_line_new_on_layer_merge -> pcb_line_new_merge +pcb_line_new_on_layer -> pcb_line_new +RemoveLine -> pcb_line_destroy +pcb_pad_new -> pcb_pad_alloc +pcb_pad_new_in_element -> pcb_element_pad_new +pcb_via_new -> pcb_via_alloc +pcb_pin_new -> pcb_pin_alloc +pcb_via_new_on_board -> pcb_via_new +pcb_pin_new_in_element -> pcb_element_pin_new +pcb_rats_delete -> pcb_rats_destroy +RemoveText -> pcb_text_destroy +SetArcBoundingBox -> pcb_arc_bbox +SetElementBoundingBox -> pcb_element_bbox +SetLineBoundingBox -> pcb_line_bbox +SetTextBoundingBox -> pcb_text_bbox +RotateArcLowLevel -> pcb_arc_rotate90 +RotateElementLowLevel -> pcb_element_rotate90 +RotateLineLowLevel -> pcb_line_rotate90 +RotatePolygonLowLevel -> pcb_poly_rotate90 +RotateTextLowLevel -> pcb_text_rotate90 +Freepcb_element_rotate90 -> pcb_element_rotate +Freepcb_element_rotate90 -> pcb_element_rotate +Freepcb_buffer_rotate -> pcb_buffer_free_rotate +GetArcEnds -> pcb_arc_get_ends +ChangeArcAngles -> pcb_arc_set_angles +ChangeArcRadii -> pcb_arc_set_radii +ChangeElementSide -> pcb_element_change_side +ChangeSelectedElementSide -> pcb_selected_element_change_side +ElementOrientation -> pcb_element_get_orientation +ChangePaste -> pcb_pad_change_paste +ChangeHole -> pcb_pin_change_hole +CreateNewElement -> pcb_element_new +CreateNewArcInElement -> pcb_element_arc_new +CreateNewLineInElement -> pcb_element_line_new +RemoveElement -> pcb_element_remove +MoveElementLowLevel -> pcb_element_move +MirrorElementCoordinates -> pcb_element_mirror +MovePolygonLowLevel -> pcb_poly_move +CopyPolygonLowLevel -> pcb_poly_copy +MOVE_TEXT_LOWLEVEL -> pcb_text_move +TEXT_IS_VISIBLE -> pcb_text_is_visible +MOVE_ARC_LOWLEVEL -> pcb_arc_move +MOVE_LINE_LOWLEVEL -> pcb_line_move +MOVE_PAD_LOWLEVEL -> pcb_pad_move +MOVE_PIN_LOWLEVEL -> pcb_pin_move +MOVE_VIA_LOWLEVEL -> pcb_via_move +ALLARC_LOOP -> PCB_ARC_ALL_LOOP +COPPERARC_LOOP -> PCB_ARC_COPPER_LOOP +SILKARC_LOOP -> PCB_ARC_SILK_LOOP +VISIBLEARC_LOOP -> PCB_ARC_VISIBLE_LOOP +ARC_LOOP -> PCB_ARC_LOOP +ELEMENTTEXT_LOOP -> PCB_ELEMENT_TEXT_LOOP +ELEMENTNAME_LOOP -> PCB_ELEMENT_NAME_LOOP +ELEMENTLINE_LOOP -> PCB_ELEMENT_LINE_LOOP +ELEMENTPCB_ARC_LOOP -> PCB_ELEMENT_ARC_LOOP +ELEMENT_LOOP -> PCB_ELEMENT_LOOP +ALLLINE_LOOP -> PCB_LINE_ALL_LOOP +COPPERLINE_LOOP -> PCB_LINE_COPPER_LOOP +SILKLINE_LOOP -> PCB_LINE_SILK_LOOP +VISIBLELINE_LOOP -> PCB_LINE_VISIBLE_LOOP +LINE_LOOP -> PCB_LINE_LOOP +ALLPAD_LOOP -> PCB_PAD_ALL_LOOP +PAD_LOOP -> PCB_PAD_LOOP +ALLPIN_LOOP -> PCB_PIN_ALL_LOOP +VIA_LOOP -> PCB_VIA_LOOP +PIN_LOOP -> PCB_PIN_LOOP +POLYGONPOINT_LOOP -> PCB_POLY_POINT_LOOP +ALLPOLYGON_LOOP -> PCB_POLY_ALL_LOOP +COPPERPOLYGON_LOOP -> PCB_POLY_COPPER_LOOP +SILKPOLYGON_LOOP -> PCB_POLY_SILK_LOOP +VISIBLEPOLYGON_LOOP -> PCB_POLY_VISIBLE_LOOP +POLYGON_LOOP -> PCB_POLY_LOOP +ALLTEXT_LOOP -> PCB_TEXT_ALL_LOOP +VISIBLETEXT_LOOP -> PCB_TEXT_VISIBLE_LOOP +TEXT_LOOP -> PCB_TEXT_LOOP +LoadElementToBuffer -> pcb_element_load_to_buffer +LoadFootprintByName -> pcb_element_load_footprint_by_name +SmashBufferElement -> pcb_element_smash_buffer +ConvertBufferToElement -> pcb_element_convert_from_buffer +CopyElementLowLevel -> pcb_element_copy +UniqueElementName -> pcb_element_uniq_name +AddTextToElement -> pcb_element_text_set +ChangeElementText -> pcb_element_text_change +resolve_path -> pcb_path_resolve +resolve_path_inplace -> pcb_path_resolve_inplace +resolve_paths -> pcb_paths_resolve +resolve_all_paths -> pcb_paths_resolve_all +fp_fopen -> pcb_fp_fopen +fp_fclose -> pcb_fp_fclose +fp_dupname -> pcb_fp_dupname +fp_tagname -> pcb_fp_tagname +fp_uninit -> pcb_fp_uninit +fp_tag -> pcb_fp_tag +fp_init -> pcb_fp_init +get_library_memory -> pcb_get_library_memory +fp_free_children -> pcb_fp_free_children +fp_sort_children -> pcb_fp_sort_children +fp_rmdir -> pcb_fp_rmdir +fp_mkdir_p -> pcb_fp_mkdir_p +fp_mkdir_len -> pcb_fp_mkdir_len +fp_lib_search -> pcb_fp_lib_search +fp_append_entry -> pcb_fp_append_entry +fp_read_lib_all -> pcb_fp_read_lib_all +fp_default_search_path -> pcb_fp_default_search_path +fp_host_uninit -> pcb_fp_host_uninit +fp_rehash -> pcb_fp_rehash +ImportNetlist -> pcb_import_netlist +ParsePCB -> pcb_parse_pcb +ParseElement -> pcb_parse_element +ParseFont -> pcb_parse_font +WriteBuffer -> pcb_write_buffer +WriteElementData -> pcb_write_element_data +CheckAndOpenFile -> pcb_check_and_open_file +OpenConnectionDataFile -> pcb_open_connection_file +SavePCB -> pcb_save_pcb +LoadPCB -> pcb_load_pcb +EnableAutosave -> pcb_enable_autosave +Backup -> pcb_backup +SaveInTMP -> pcb_save_in_tmp +EmergencySave -> pcb_emergency_save +DisableEmergencySave -> pcb_disable_emergency_save +RevertPCB -> pcb_revert_pcb +SaveBufferElements -> pcb_save_buffer_elements +PrintQuotedString -> pcb_print_quoted_string +sort_library -> pcb_library_sort +set_some_route_style -> pcb_set_some_route_style +WritePCBFile -> pcb_write_pcb_file +WritePipe -> pcb_write_pipe +SaveTMPData -> pcb_tmp_data_save +RemoveTMPData -> pcb_tmp_data_remove +plugins_init -> pcb_plugins_init +plugins_uninit -> pcb_plugins_uninit +plugin_register -> pcb_plugin_register +HOOK_CALL_DO -> PCB_HOOK_CALL_DO +HOOK_CALL_ALL -> PCB_HOOK_CALL_ALL +HOOK_UNREGISTER -> PCB_HOOK_UNREGISTER +HOOK_CALL -> PCB_HOOK_CALL +HOOK_REGISTER -> PCB_HOOK_REGISTER +poly_NewContour -> pcb_poly_contour_new +poly_IniContour -> pcb_poly_contour_init +poly_ClrContour -> pcb_poly_contour_clear +poly_DelContour -> pcb_poly_contour_del +poly_CopyContour -> pcb_poly_contour_copy +poly_PreContour -> pcb_poly_contour_pre +poly_InvContour -> pcb_poly_contour_inv +poly_CreateNode -> pcb_poly_node_create +poly_InclVertex -> pcb_poly_vertex_include +poly_ExclVertex -> pcb_poly_vertex_exclude +poly_M_Copy0 -> pcb_poly_m_copy0 +poly_M_Incl -> pcb_poly_m_include +poly_Copy0 -> pcb_poly_copy0 +poly_Copy1 -> pcb_poly_copy1 +poly_InclContour -> pcb_poly_contour_include +poly_ExclContour -> pcb_poly_contour_exclide +poly_ChkContour -> pcb_poly_contour_check +poly_CheckInside -> pcb_poly_contour_inside +Touching -> pcb_poly_touching +pcb_poly_m_copy0 -> pcb_polyarea_m_copy0 +pcb_poly_m_include -> pcb_polyarea_m_include +pcb_poly_copy0 -> pcb_polyarea_copy0 +pcb_poly_copy1 -> pcb_polyarea_copy1 +pcb_poly_contour_include -> pcb_polyarea_contour_include +pcb_poly_contour_exclide -> pcb_polyarea_contour_exclide +pcb_poly_contour_check -> pcb_polyarea_contour_check +pcb_poly_contour_inside -> pcb_polyarea_contour_inside +pcb_poly_touching -> pcb_polyarea_touching +poly_InsideContour -> pcb_poly_contour_inside +poly_ContourInContour -> pcb_poly_contour_in_contour +poly_Create -> pcb_polyarea_create +poly_Free -> pcb_polyarea_free +poly_Init -> pcb_polyarea_init +poly_FreeContours -> pcb_poly_contours_free +poly_Valid -> pcb_poly_valid +vect_dist2 -> pcb_vect_dist2 +vect_det2 -> pcb_vect_det2 +vect_len2 -> pcb_vect_len2 +vect_inters2 -> pcb_vect_inters2 +poly_Boolean -> pcb_polyarea_boolean +poly_Boolean_free -> pcb_polyarea_boolean_free +poly_AndSubtract_free -> pcb_polyarea_and_subtract_free +poly_bbox -> pcb_polyarea_bbox +Savepcb_polyarea_t -> pcb_polyarea_save +polygon_init -> pcb_polygon_init +polygon_point_idx -> pcb_poly_point_idx +polygon_point_contour -> pcb_poly_contour_point +prev_contour_point -> pcb_poly_contour_prev_point +next_contour_point -> pcb_poly_contour_next_point +GetLowestDistancePolygonPoint -> pcb_poly_get_lowest_distance_point +RemoveExcessPolygonPoints -> pcb_poly_remove_excess_points +GoToPreviousPoint -> pcb_polygon_go_to_prev_point +ClosePolygon -> pcb_polygon_close_poly +CopyAttachedPolygonToLayer -> pcb_polygon_copy_attached_to_layer +PolygonHoles -> pcb_poly_holes +PlowsPolygon -> pcb_poly_plows +ComputeNoHoles -> pcb_poly_compute_no_holes +ContourToPoly -> pcb_poly_from_contour +PolygonToPoly -> pcb_poly_from_poly +RectPoly -> pcb_poly_from_rect +CirclePoly -> pcb_poly_from_circle +OctagonPoly -> pcb_poly_from_octagon +LinePoly -> pcb_poly_from_line +ArcPoly -> pcb_poly_from_arc +PinPoly -> pcb_poly_from_pin +BoxPolyBloated -> pcb_poly_from_box_bloated +ContourToPoly -> pcb_poly_from_contour +PolygonToPoly -> pcb_poly_from_poly +RectPoly -> pcb_poly_from_rect +CirclePoly -> pcb_poly_from_circle +OctagonPoly -> pcb_poly_from_octagon +LinePoly -> pcb_poly_from_line +ArcPoly -> pcb_poly_from_arc +PinPoly -> pcb_poly_from_pin +BoxPolyBloated -> pcb_poly_from_box_bloated +frac_circle -> pcb_poly_frac_cicle +InitClip -> pcb_poly_init_clip +RestoreToPolygon -> pcb_poly_restore_to_poly +ClearFromPolygon -> pcb_poly_clear_from_poly +IsPointInPolygon -> pcb_poly_is_point_in_p +IsPointInPolygonIgnoreHoles -> pcb_poly_is_point_in_p_ignore_holes +IsRectangleInPolygon -> pcb_poly_is_rect_in_p +isects -> pcb_poly_isects_poly +MorphPolygon -> pcb_poly_morph +NoHolesPolygonDicer -> pcb_poly_no_holes_dicer +PolyToPolygonsOnLayer -> pcb_poly_to_polygons_on_layer +square_pin_factors -> pcb_poly_square_pin_factors +AddNet -> pcb_rat_add_net +ConnectionName -> pcb_connection_name +AddAllRats -> pcb_rat_add_all +SeekPad -> pcb_rat_seek_pad +ProcNetlist -> pcb_rat_proc_netlist +CollectSubnets -> pcb_rat_collect_subnets +GetConnectionMemory -> pcb_rat_connection_alloc +CONNECTION_LOOP -> PCB_CONNECTION_LOOP +RAT_LOOP -> PCB_RAT_LOOP +rats_patch_append -> pcb_ratspatch_append +rats_patch_destroy -> pcb_ratspatch_destroy +rats_patch_append_optimize -> pcb_ratspatch_append_optimize +rats_patch_make_edited -> pcb_ratspatch_make_edited +rats_patch_apply -> pcb_ratspatch_apply +rats_patch_fexport -> pcb_ratspatch_fexport +RemovePCB -> pcb_board_remove +RemoveSelected -> pcb_remove_selected +RemoveObject -> pcb_remove_object +DestroyObject -> pcb_destroy_object +ROTATE -> PCB_ROTATE90 +PIN_ROTATE -> PCB_PIN_ROTATE_SHAPE +ROTATE_VIA_LOWLEVEL -> PCB_VIA_ROTATE90 +ROTATE_PIN_LOWLEVEL -> PCB_PIN_ROTATE90 +ROTATE_PAD_LOWLEVEL -> PCB_PAD_ROTATE90 +RotateBoxLowLevel -> pcb_box_rotate90 +RotateObject -> pcb_obj_rotate90 +RotateScreenObject -> pcb_screen_obj_rotate90 +RotatePointLowLevel -> pcb_point_rotate90 +free_rotate -> pcb_rotate +PCB_ROTATE90 -> PCB_COORD_ROTATE90 +ParseRoutingString1 -> pcb_route_string_parse1 +ParseRouteString -> pcb_route_string_parse +make_route_string -> pcb_route_string_make +r_create_tree -> pcb_r_create_tree +r_destroy_tree -> pcb_r_destroy_tree +r_delete_entry -> pcb_r_delete_entry +r_insert_entry -> pcb_r_insert_entry +r_search -> pcb_r_search +r_region_is_empty -> pcb_r_region_is_empty +__r_dump_tree -> pcb_r_dump_tree +LookupRubberbandLines -> pcb_rubber_band_lookup_lines +LookupRatLines -> pcb_rubber_band_lookup_rat_lines +GetRubberbandMemory -> pcb_rubber_band_alloc +CreateNewRubberbandEntry -> pcb_rubber_band_create +IsPointOnLine -> pcb_is_point_on_line +IsPointOnPin -> pcb_is_point_in_pin +IsPointOnArc -> pcb_is_point_on_arc +IsPointOnLineEnd -> pcb_is_point_on_line_end +IsLineInRectangle -> pcb_is_line_in_rectangle +IsLineInQuadrangle -> pcb_is_line_in_quadrangle +IsArcInRectangle -> pcb_is_arc_in_rectangle +IsPointInPad -> pcb_is_point_in_pad +IsPointInBox -> pcb_is_point_in_box +lines_intersect -> pcb_lines_intersect +POINT_IN_BOX -> PCB_POINT_IN_BOX +VIA_OR_PIN_IN_BOX -> PCB_VIA_OR_PIN_IN_BOX +LINE_IN_BOX -> PCB_LINE_IN_BOX +PAD_IN_BOX -> PCB_PAD_IN_BOX +BOX_IN_BOX -> PCB_BOX_IN_BOX +TEXT_IN_BOX -> PCB_TEXT_IN_BOX +POLYGON_IN_BOX -> PCB_POLYGON_IN_BOX +ELEMENT_IN_BOX -> PCB_ELEMENT_IN_BOX +ARC_IN_BOX -> PCB_ARC_IN_BOX +POINT_IN_CIRCLE -> PCB_POINT_IN_CIRCLE +CIRCLE_TOUCHES_BOX -> PCB_CIRCLE_TOUCHES_BOX +VIA_OR_PIN_TOUCHES_BOX -> PCB_VIA_OR_PIN_TOUCHES_BOX +LINE_TOUCHES_BOX -> PCB_LINE_TOUCHES_BOX +PAD_TOUCHES_BOX -> PCB_PAD_TOUCHES_BOX +BOX_TOUCHES_BOX -> PCB_BOX_TOUCHES_BOX +TEXT_TOUCHES_BOX -> PCB_TEXT_TOUCHES_BOX +POLYGON_TOUCHES_BOX -> PCB_POLYGON_TOUCHES_BOX +ELEMENT_TOUCHES_BOX -> PCB_ELEMENT_TOUCHES_BOX +ARC_TOUCHES_BOX -> PCB_ARC_TOUCHES_BOX +IS_BOX_NEGATIVE -> PCB_IS_BOX_NEGATIVE +BOX_NEAR_BOX -> PCB_BOX_NEAR_BOX +VIA_OR_PIN_NEAR_BOX -> PCB_VIA_OR_PIN_NEAR_BOX +LINE_NEAR_BOX -> PCB_LINE_NEAR_BOX +PAD_NEAR_BOX -> PCB_PAD_NEAR_BOX +TEXT_NEAR_BOX -> PCB_TEXT_NEAR_BOX +POLYGON_NEAR_BOX -> PCB_POLYGON_NEAR_BOX +ELEMENT_NEAR_BOX -> PCB_ELEMENT_NEAR_BOX +ARC_NEAR_BOX -> PCB_ARC_NEAR_BOX +SearchObjectByLocation -> pcb_search_obj_by_location +SearchScreen -> pcb_search_screen +SearchScreenGridSlop -> pcb_search_grid_slop +SearchObjectByID -> pcb_search_obj_by_id +SearchElementByName -> pcb_search_elem_by_name +SelectObject -> pcb_select_object +SelectBlock -> pcb_select_block +ListBlock -> pcb_list_block +ObjectOperation -> pcb_object_operation +SelectedOperation -> pcb_selected_operation +SelectConnection -> pcb_select_connection +SelectObjectByName -> pcb_select_object_by_name +SetTextScale -> pcb_text_set_scale +SetGrid -> pcb_board_set_grid +SetLineSize -> pcb_line_set_size +SetViaSize -> pcb_via_set_size +SetViaDrillingHole -> pcb_via_set_drilling_hole +SetClearanceWidth -> pcb_conf_set_clearance_width +SetChangedFlag -> pcb_board_set_changed_flag +SetBufferNumber -> pcb_buffer_set_number +SetMode -> pcb_crosshair_set_mode +SetCrosshairRangeToBuffer -> pcb_crosshair_range_to_buffer +SetLocalRef -> pcb_crosshair_set_local_ref +SaveMode -> pcb_crosshair_save_mode +RestoreMode -> pcb_crosshair_restore_mode +pcb_text_set_scale -> pcb_board_set_text_scale +pcb_line_set_size -> pcb_board_set_line_width +pcb_via_set_size -> pcb_board_set_via_size +pcb_via_set_drilling_hole -> pcb_board_set_via_drilling_hole +pcb_conf_set_clearance_width -> pcb_board_set_clearance +stub_DrawFab_overhang -> pcb_stub_draw_fab_overhang +stub_DrawFab -> pcb_stub_draw_fab +stub_rat_found_short -> pcb_stub_rat_found_short +stub_rat_proc_shorts -> pcb_stub_rat_proc_shorts +Undo -> pcb_undo +Redo -> pcb_redo +IncrementUndoSerialNumber -> pcb_undo_inc_serial +SaveUndoSerialNumber -> pcb_undo_save_serial +RestoreUndoSerialNumber -> pcb_undo_restore_serial +ClearUndoList -> pcb_undo_clear_list +LockUndo -> pcb_undo_lock +UnlockUndo -> pcb_undo_unlock +Undoing -> pcb_undoing +MoveObjectToRemoveUndoList -> pcb_undo_move_obj_to_remove +AddObjectToRemovePointUndoList -> pcb_undo_add_obj_to_remove_point +AddObjectToInsertPointUndoList -> pcb_undo_add_obj_to_insert_point +AddObjectToRemoveContourUndoList -> pcb_undo_add_obj_to_remove_contour +AddObjectToInsertContourUndoList -> pcb_undo_add_obj_to_insert_contour +AddObjectToMoveUndoList -> pcb_undo_add_obj_to_move +AddObjectToChangeNameUndoList -> pcb_undo_add_obj_to_change_name +AddObjectToChangePinnumUndoList -> pcb_undo_add_obj_to_change_pinnum +AddObjectToRotateUndoList -> pcb_undo_add_obj_to_rotate +AddObjectToCreateUndoList -> pcb_undo_add_obj_to_create +AddObjectToMirrorUndoList -> pcb_undo_add_obj_to_mirror +AddObjectToMoveToLayerUndoList -> pcb_undo_add_obj_to_move_to_layer +AddObjectToFlagUndoList -> pcb_undo_add_obj_to_flag +AddObjectToSizeUndoList -> pcb_undo_add_obj_to_size +AddObjectTo2ndSizeUndoList -> pcb_undo_add_obj_to_2nd_size +AddObjectToClearSizeUndoList -> pcb_undo_add_obj_to_clear_size +AddObjectToMaskSizeUndoList -> pcb_undo_add_obj_to_mask_size +AddObjectToChangeAnglesUndoList -> pcb_undo_add_obj_to_change_angles +AddObjectToChangeRadiiUndoList -> pcb_undo_add_obj_to_change_radii +AddObjectToClearPolyUndoList -> pcb_undo_add_obj_to_clear_poly +AddLayerChangeToUndoList -> pcb_undo_add_layer_change +AddNetlistLibToUndoList -> pcb_undo_add_netlist_lib +get_n_units -> pcb_get_n_units +coord_to_unit -> pcb_coord_to_unit +unit_to_factor -> pcb_unit_to_factor +unit_to_coord -> pcb_unit_to_coord +get_increments_struct -> pcb_get_increments_struct +NormalizeAngle -> pcb_normalize_angle +initialize_units -> pcb_units_init +UNDO_CHANGENAME -> PCB_UNDO_CHANGENAME +UNDO_MOVE -> PCB_UNDO_MOVE +UNDO_REMOVE -> PCB_UNDO_REMOVE +UNDO_REMOVE_POINT -> PCB_UNDO_REMOVE_POINT +UNDO_INSERT_POINT -> PCB_UNDO_INSERT_POINT +UNDO_REMOVE_CONTOUR -> PCB_UNDO_REMOVE_CONTOUR +UNDO_INSERT_CONTOUR -> PCB_UNDO_INSERT_CONTOUR +UNDO_ROTATE -> PCB_UNDO_ROTATE +UNDO_CREATE -> PCB_UNDO_CREATE +UNDO_MOVETOLAYER -> PCB_UNDO_MOVETOLAYER +UNDO_FLAG -> PCB_UNDO_FLAG +UNDO_CHANGESIZE -> PCB_UNDO_CHANGESIZE +UNDO_CHANGE2NDSIZE -> PCB_UNDO_CHANGE2NDSIZE +UNDO_MIRROR -> PCB_UNDO_MIRROR +UNDO_CHANGECLEARSIZE -> PCB_UNDO_CHANGECLEARSIZE +UNDO_CHANGEMASKSIZE -> PCB_UNDO_CHANGEMASKSIZE +UNDO_CHANGEANGLES -> PCB_UNDO_CHANGEANGLES +UNDO_LAYERCHANGE -> PCB_UNDO_LAYERCHANGE +UNDO_CLEAR -> PCB_UNDO_CLEAR +UNDO_NETLISTCHANGE -> PCB_UNDO_NETLISTCHANGE +UNDO_CHANGEPINNUM -> PCB_UNDO_CHANGEPINNUM +UNDO_CHANGERADII -> PCB_UNDO_CHANGERADII +ROTATE_TYPES -> PCB_ROTATE_TYPES +CHANGENAME_TYPES -> PCB_CHANGENAME_TYPES +CHANGESIZE_TYPES -> PCB_CHANGESIZE_TYPES +CHANGE2NDSIZE_TYPES -> PCB_CHANGE2NDSIZE_TYPES +CHANGECLEARSIZE_TYPES -> PCB_CHANGECLEARSIZE_TYPES +CHANGENONETLIST_TYPES -> PCB_CHANGENONETLIST_TYPES +CHANGESQUARE_TYPES -> PCB_CHANGESQUARE_TYPES +CHANGEOCTAGON_TYPES -> PCB_CHANGEOCTAGON_TYPES +CHANGEJOIN_TYPES -> PCB_CHANGEJOIN_TYPES +CHANGETHERMAL_TYPES -> PCB_CHANGETHERMAL_TYPES +CHANGEMASKSIZE_TYPES -> PCB_CHANGEMASKSIZE_TYPES +SELECT_TYPES -> PCB_SELECT_TYPES +MOVE_TYPES -> PCB_MOVE_TYPES +MOVETOLAYER_TYPES -> PCB_MOVETOLAYER_TYPES +INSERT_TYPES -> PCB_INSERT_TYPES +COPY_TYPES -> PCB_COPY_TYPES +REMOVE_TYPES -> PCB_REMOVE_TYPES +NETLIST_INPUT -> PCB_NETLIST_INPUT +NETLIST_EDITED -> PCB_NETLIST_EDITED +NUM_NETLISTS -> PCB_NUM_NETLISTS +ATTRIBUTE_UNUSED -> PCB_ATTRIBUTE_UNUSED +UNLIKELY -> PCB_UNLIKELY +LIKELY -> PCB_LIKELY +STATE_FIRST -> PCB_CH_STATE_FIRST +STATE_SECOND -> PCB_CH_STATE_SECOND +STATE_THIRD -> PCB_CH_STATE_THIRD +Basic_Crosshair_Shape -> pcb_ch_shape_basic +Union_Jack_Crosshair_Shape -> pcb_ch_shape_union_jack +Dozen_Crosshair_Shape -> pcb_ch_shape_dozen +Crosshair_Shapes_Number -> pcb_ch_shape_NUM +Crosshair -> pcb_crosshair +Marked -> pcb_marked +max_group -> pcb_max_group +max_copper_layer -> pcb_max_copper_layer +solder_silk_layer -> pcb_solder_silk_layer +component_silk_layer -> pcb_component_silk_layer +Buffers -> pcb_buffers +addedLines -> pcb_added_lines +LayerStack -> pcb_layer_stack +Bumped -> pcb_bumped +STATUS_OK -> 0 +STATUS_ERROR -> -1 +EVENT_GUI_INIT -> PCB_EVENT_GUI_INIT +EVENT_CLI_ENTER -> PCB_EVENT_CLI_ENTER +EVENT_SAVE_PRE -> PCB_EVENT_SAVE_PRE +EVENT_SAVE_POST -> PCB_EVENT_SAVE_POST +EVENT_LOAD_PRE -> PCB_EVENT_LOAD_PRE +EVENT_LOAD_POST -> PCB_EVENT_LOAD_POST +EVENT_last -> PCB_EVENT_last +ARG_INT -> PCB_EVARG_INT +ARG_DOUBLE -> PCB_EVARG_DOUBLE +ARG_STR -> PCB_EVARG_STR +LOOKUP_FIRST -> PCB_LOOKUP_FIRST +LOOKUP_MORE -> PCB_LOOKUP_MORE +SILK_TYPE -> PCB_SILK_TYPE +FCT_COPPER -> PCB_FCT_COPPER +FCT_INTERNAL -> PCB_FCT_INTERNAL +FCT_RAT -> PCB_FCT_RAT +FCT_ELEMENT -> PCB_FCT_ELEMENT +FCT_START -> PCB_FCT_START +find_callback_t -> pcb_find_callback_t +find_callback -> pcb_find_callback +SHOWNUMBERFLAG -> PCB_SHOWNUMBERFLAG +LOCALREFFLAG -> PCB_LOCALREFFLAG +CHECKPLANESFLAG -> PCB_CHECKPLANESFLAG +SHOWPCB_FLAG_DRC -> PCB_SHOWPCB_FLAG_DRC +RUBBERBANDFLAG -> PCB_RUBBERBANDFLAG +DESCRIPTIONFLAG -> PCB_DESCRIPTIONFLAG +NAMEONPCBFLAG -> PCB_NAMEONPCBFLAG +AUTOPCB_FLAG_DRC -> PCB_AUTOPCB_FLAG_DRC +ALLDIRECTIONFLAG -> PCB_ALLDIRECTIONFLAG +SWAPSTARTDIRFLAG -> PCB_SWAPSTARTDIRFLAG +UNIQUENAMEFLAG -> PCB_UNIQUENAMEFLAG +CLEARNEWFLAG -> PCB_CLEARNEWFLAG +SNAPPCB_FLAG_PIN -> PCB_SNAPPCB_FLAG_PIN +SHOWMASKFLAG -> PCB_SHOWMASKFLAG +THINDRAWFLAG -> PCB_THINDRAWFLAG +ORTHOMOVEFLAG -> PCB_ORTHOMOVEFLAG +LIVEROUTEFLAG -> PCB_LIVEROUTEFLAG +THINDRAWPOLYFLAG -> PCB_THINDRAWPOLYFLAG +LOCKNAMESFLAG -> PCB_LOCKNAMESFLAG +ONLYNAMESFLAG -> PCB_ONLYNAMESFLAG +NEWPCB_FLAG_FULLPOLY -> PCB_NEWPCB_FLAG_FULLPOLY +HIDENAMESFLAG -> PCB_HIDENAMESFLAG +ENABLEPCB_FLAG_MINCUT -> PCB_ENABLEPCB_FLAG_MINCUT +GROUNDPLANEFRAME -> PCB_GROUNDPLANEFRAME +MASKFRAME -> PCB_MASKFRAME +LARGE_VALUE -> PCB_LARGE_VALUE +MAX_LAYER -> PCB_MAX_LAYER +MIN_LINESIZE -> PCB_MIN_LINESIZE +MAX_LINESIZE -> PCB_MAX_LINESIZE +MIN_ARCSIZE -> PCB_MIN_ARCSIZE +MAX_ARCSIZE -> PCB_MAX_ARCSIZE +MIN_TEXTSCALE -> PCB_MIN_TEXTSCALE +MAX_TEXTSCALE -> PCB_MAX_TEXTSCALE +MIN_PINORVIASIZE -> PCB_MIN_PINORVIASIZE +MIN_PINORVIAHOLE -> PCB_MIN_PINORVIAHOLE +MAX_PINORVIASIZE -> PCB_MAX_PINORVIASIZE +MIN_PINORVIACOPPER -> PCB_MIN_PINORVIACOPPER +MIN_PADSIZE -> PCB_MIN_PADSIZE +MAX_PADSIZE -> PCB_MAX_PADSIZE +MIN_DRC_VALUE -> PCB_MIN_DRC_VALUE +MAX_DRC_VALUE -> PCB_MAX_DRC_VALUE +MIN_DRC_SILK -> PCB_MIN_DRC_SILK +MAX_DRC_SILK -> PCB_MAX_DRC_SILK +MIN_DRC_DRILL -> PCB_MIN_DRC_DRILL +MAX_DRC_DRILL -> PCB_MAX_DRC_DRILL +MIN_DRC_RING -> PCB_MIN_DRC_RING +MAX_DRC_RING -> PCB_MAX_DRC_RING +MIN_GRID -> PCB_MIN_GRID +MAX_GRID -> PCB_MAX_GRID +MAX_FONTPOSITION -> PCB_MAX_FONTPOSITION +MAX_COORD -> PCB_MAX_COORD +MIN_SIZE -> PCB_MIN_SIZE +MAX_SIZE -> PCB_MAX_SIZE +MAX_BUFFER -> PCB_MAX_BUFFER +DEFAULT_DRILLINGHOLE -> PCB_DEFAULT_DRILLINGHOLE +MAXPATHLEN -> PCB_PATH_MAX +MAX_LINE_POINT_DISTANCE -> PCB_MAX_LINE_POINT_DISTANCE +MAX_POLYGON_POINT_DISTANCE -> PCB_MAX_POLYGON_POINT_DISTANCE +MAX_ELEMENTNAMES -> PCB_MAX_ELEMENTNAMES +MAX_NETLIST_LINE_LENGTH -> PCB_MAX_NETLIST_LINE_LENGTH +MAX_MODESTACK_DEPTH -> PCB_MAX_MODESTACK_DEPTH +MIN_GRID_DISTANCE -> PCB_MIN_GRID_DISTANCE +EMARK_SIZE -> PCB_EMARK_SIZE +FONT_CAPHEIGHT -> PCB_FONT_CAPHEIGHT +DEFAULT_CELLSIZE -> PCB_DEFAULT_CELLSIZE +next_gui -> pcb_next_gui +current_action -> pcb_current_action +pixel_slop -> pcb_pixel_slop +MF_ACCELERATOR -> PCB_MF_ACCELERATOR +MF_MNEMONIC -> PCB_MF_MNEMONIC +MF_SUBMENU -> PCB_MF_SUBMENU +MF_CHECKED -> PCB_MF_CHECKED +MF_UPDATE_ON -> PCB_MF_UPDATE_ON +MF_SENSITIVE -> PCB_MF_SENSITIVE +MF_TIP -> PCB_MF_TIP +MF_ACTIVE -> PCB_MF_ACTIVE +MF_ACTION -> PCB_MF_ACTION +MF_FOREGROUND -> PCB_MF_FOREGROUND +MF_BACKGROUND -> PCB_MF_BACKGROUND +MF_FONT -> PCB_MF_FONT +M_Shift -> PCB_M_Shift +M_Ctrl -> PCB_M_Ctrl +M_Alt -> PCB_M_Alt +M_Mod1 -> PCB_M_Mod1 +M_Release -> PCB_M_Release +MB_LEFT -> PCB_MB_LEFT +MB_MIDDLE -> PCB_MB_MIDDLE +MB_RIGHT -> PCB_MB_RIGHT +MB_SCROLL_UP -> PCB_MB_SCROLL_UP +MB_SCROLL_DOWN -> PCB_MB_SCROLL_DOWN +MB_SCROLL_LEFT -> PCB_MB_SCROLL_LEFT +MB_SCROLL_RIGHT -> PCB_MB_SCROLL_RIGHT +MB_ANY -> PCB_MB_ANY +M_ANY -> PCB_M_ANY +hid_list -> pcb_hid_list +hid_num_hids -> pcb_hid_num_hids +MENU_LOOP -> PCB_MENU_LOOP +ENTRY_LOOP -> PCB_ENTRY_LOOP +SWAP_IDENT -> PCB_SWAP_IDENT +END_LOOP -> PCB_END_LOOP +ENDALL_LOOP -> PCB_ENDALL_LOOP +pcb_create_be_lenient -> pcb_create_being_lenient +CreateBeLenient -> pcb_create_be_lenient +CreateIDBump -> pcb_create_ID_bump +CreateIDReset -> pcb_create_ID_reset +CreateIDGet -> pcb_create_ID_get +DESCRIPTION_INDEX -> PCB_ELEMNAME_IDX_DESCRIPTION +NAMEONPCB_INDEX -> PCB_ELEMNAME_IDX_REFDES +VALUE_INDEX -> PCB_ELEMNAME_IDX_VALUE +NAME_INDEX -> PCB_ELEMNAME_IDX_VISIBLE +ELEMENT_NAME -> PCB_ELEM_NAME_VISIBLE +DESCRIPTION_NAME -> PCB_ELEM_NAME_DESCRIPTION +NAMEONPCB_NAME -> PCB_ELEM_NAME_REFDES +VALUE_NAME -> PCB_ELEM_NAME_VALUE +ELEMENT_TEXT -> PCB_ELEM_TEXT_VISIBLE +DESCRIPTION_TEXT -> PCB_ELEM_TEXT_DESCRIPTION +NAMEONPCB_TEXT -> PCB_ELEM_TEXT_REFDES +VALUE_TEXT -> PCB_ELEM_TEXT_VALUE +AdjustAttachedLine -> pcb_line_adjust_attached +AdjustTwoLine -> pcb_line_adjust_attached_2lines +FortyFiveLine -> pcb_line_45 +EnforceLineDRC -> pcb_line_enforce_drc +library -> pcb_library +gui -> pcb_gui +exporter -> pcb_exporter +plug_fp_chain -> pcb_plug_fp_chain +plug_import_chain -> pcb_plug_import_chain +plug_io_chain -> pcb_plug_io_chain +PLF_DIR -> PCB_PLF_DIR +PLF_INV -> PCB_PLF_INV +PLF_MARK -> PCB_PLF_MARK +VertexEqu -> pcb_vertex_equ +VertexCpy -> pcb_vertex_cpy +err_no_memory -> pcb_err_no_memory +err_bad_parm -> pcb_err_bad_parm +err_ok -> pcb_err_ok +PBO_UNITE -> PCB_PBO_UNITE +PBO_ISECT -> PCB_PBO_ISECT +PBO_SUB -> PCB_PBO_SUB +PBO_XOR -> PCB_PBO_XOR +POLY_CIRC_SEGS -> PCB_POLY_CIRC_SEGS +POLY_CIRC_SEGS_F -> PCB_POLY_CIRC_SEGS_F +POLY_CIRC_RADIUS_ADJ -> PCB_POLY_CIRC_RADIUS_ADJ +POLY_ARC_MAX_DEVIATION -> PCB_POLY_ARC_MAX_DEVIATION +R_DIR_NOT_FOUND -> PCB_R_DIR_NOT_FOUND +R_DIR_FOUND_CONTINUE -> PCB_R_DIR_FOUND_CONTINUE +R_DIR_CANCEL -> PCB_R_DIR_CANCEL +SLOP -> PCB_SLOP +SM_REGEX -> PCB_SM_REGEX +SM_LIST -> PCB_SM_LIST +SWAP_ANGLE -> PCB_SWAP_ANGLE +SWAP_DELTA -> PCB_SWAP_DELTA +METRIC -> PCB_UNIT_METRIC +IMPERIAL -> PCB_UNIT_IMPERIAL +NO_SUFFIX -> PCB_UNIT_NO_SUFFIX +SUFFIX -> PCB_UNIT_SUFFIX +FILE_MODE -> PCB_UNIT_FILE_MODE +NO_PRINT -> PCB_UNIT_NO_PRINT +ALLOW_NM -> PCB_UNIT_ALLOW_NM +ALLOW_UM -> PCB_UNIT_ALLOW_UM +ALLOW_MM -> PCB_UNIT_ALLOW_MM +ALLOW_CM -> PCB_UNIT_ALLOW_CM +ALLOW_M -> PCB_UNIT_ALLOW_M +ALLOW_KM -> PCB_UNIT_ALLOW_KM +ALLOW_CMIL -> PCB_UNIT_ALLOW_CMIL +ALLOW_MIL -> PCB_UNIT_ALLOW_MIL +ALLOW_IN -> PCB_UNIT_ALLOW_IN +ALLOW_DMIL -> PCB_UNIT_ALLOW_DMIL +ALLOW_METRIC -> PCB_UNIT_ALLOW_METRIC +ALLOW_IMPERIAL -> PCB_UNIT_ALLOW_IMPERIAL +ALLOW_READABLE -> PCB_UNIT_ALLOW_READABLE +ALLOW_NATURAL -> PCB_UNIT_ALLOW_NATURAL +ALLOW_ALL -> PCB_UNIT_ALLOW_ALL +ActionExecuteFile -> pcb_act_ExecuteFile +executefile_help -> pcb_acth_ExecuteFile +executefile_syntax -> pcb_acts_ExecuteFile +ActionChangeAngle -> pcb_act_ChangeAngle +changeangle_help -> pcb_acth_ChangeAngle +changeangle_syntax -> pcb_acts_ChangeAngle +ActionChangeClearSize -> pcb_act_ChangeClearSize +changeclearsize_help -> pcb_acth_ChangeClearSize +changeclearsize_syntax -> pcb_acts_ChangeClearSize +ActionChange2ndSize -> pcb_act_Change2ndSize +change2ndsize_help -> pcb_acth_Change2ndSize +change2ndsize_syntax -> pcb_acts_Change2ndSize +ActionChangeHole -> pcb_act_ChangeHole +changehole_help -> pcb_acth_ChangeHole +changehole_syntax -> pcb_acts_ChangeHole +ActionChangeJoin -> pcb_act_ChangeJoin +changejoin_help -> pcb_acth_ChangeJoin +changejoin_syntax -> pcb_acts_ChangeJoin +ActionChangeName -> pcb_act_ChangeName +changename_help -> pcb_acth_ChangeName +changename_syntax -> pcb_acts_ChangeName +ActionChangePaste -> pcb_act_ChangePaste +changepaste_help -> pcb_acth_ChangePaste +changepaste_syntax -> pcb_acts_ChangePaste +ActionChangePinName -> pcb_act_ChangePinName +changepinname_help -> pcb_acth_ChangePinName +changepinname_syntax -> pcb_acts_ChangePinName +ActionChangeRadius -> pcb_act_ChangeRadius +changeradius_help -> pcb_acth_ChangeRadius +changeradius_syntax -> pcb_acts_ChangeRadius +ActionChangeSize -> pcb_act_ChangeSize +changesize_help -> pcb_acth_ChangeSize +changesize_syntax -> pcb_acts_ChangeSize +ActionChangeSizes -> pcb_act_ChangeSizes +changesizes_help -> pcb_acth_ChangeSizes +changesizes_syntax -> pcb_acts_ChangeSizes +ActionChangeNonetlist -> pcb_act_ChangeNonetlist +changenonetlist_help -> pcb_acth_ChangeNonetlist +changenonetlist_syntax -> pcb_acts_ChangeNonetlist +ActionChangeSquare -> pcb_act_ChangeSquare +changesquare_help -> pcb_acth_ChangeSquare +changesquare_syntax -> pcb_acts_ChangeSquare +ActionChangeOctagon -> pcb_act_ChangeOctagon +changeoctagon_help -> pcb_acth_ChangeOctagon +changeoctagon_syntax -> pcb_acts_ChangeOctagon +ActionChangeFlag -> pcb_act_ChangeFlag +changeflag_help -> pcb_acth_ChangeFlag +changeflag_syntax -> pcb_acts_ChangeFlag +ActionClearSquare -> pcb_act_ClearSquare +clearsquare_help -> pcb_acth_ClearSquare +clearsquare_syntax -> pcb_acts_ClearSquare +ActionClearOctagon -> pcb_act_ClearOctagon +clearoctagon_help -> pcb_acth_ClearOctagon +clearoctagon_syntax -> pcb_acts_ClearOctagon +ActionSetSquare -> pcb_act_SetSquare +setsquare_help -> pcb_acth_SetSquare +setsquare_syntax -> pcb_acts_SetSquare +ActionSetOctagon -> pcb_act_SetOctagon +setoctagon_help -> pcb_acth_SetOctagon +setoctagon_syntax -> pcb_acts_SetOctagon +ActionSetThermal -> pcb_act_SetThermal +setthermal_help -> pcb_acth_SetThermal +setthermal_syntax -> pcb_acts_SetThermal +ActionSetValue -> pcb_act_SetValue +setvalue_help -> pcb_acth_SetValue +setvalue_syntax -> pcb_acts_SetValue +ActionSetFlag -> pcb_act_SetFlag +setflag_help -> pcb_acth_SetFlag +setflag_syntax -> pcb_acts_SetFlag +ActionClrFlag -> pcb_act_ClrFlag +clrflag_help -> pcb_acth_ClrFlag +clrflag_syntax -> pcb_acts_ClrFlag +ActionExecCommand -> pcb_act_ExecCommand +execcommand_help -> pcb_acth_ExecCommand +execcommand_syntax -> pcb_acts_ExecCommand +ActionLoadFrom -> pcb_act_LoadFrom +loadfrom_help -> pcb_acth_LoadFrom +loadfrom_syntax -> pcb_acts_LoadFrom +ActionNew -> pcb_act_New +new_help -> pcb_acth_New +new_syntax -> pcb_acts_New +ActionSaveTo -> pcb_act_SaveTo +saveto_help -> pcb_acth_SaveTo +saveto_syntax -> pcb_acts_SaveTo +ActionQuit -> pcb_act_Quit +quit_help -> pcb_acth_Quit +quit_syntax -> pcb_acts_Quit +ActionDRCheck -> pcb_act_DRCheck +drcheck_help -> pcb_acth_DRCheck +drcheck_syntax -> pcb_acts_DRCheck +ActionDisplay -> pcb_act_Display +display_help -> pcb_acth_Display +display_syntax -> pcb_acts_Display +ActionCycleDrag -> pcb_act_CycleDrag +cycledrag_help -> pcb_acth_CycleDrag +cycledrag_syntax -> pcb_acts_CycleDrag +FullScreen -> pcb_act_FullScreen +fullscreen_help -> pcb_acth_FullScreen +fullscreen_syntax -> pcb_acts_FullScreen +ActionMarkCrosshair -> pcb_act_MarkCrosshair +markcrosshair_help -> pcb_acth_MarkCrosshair +markcrosshair_syntax -> pcb_acts_MarkCrosshair +ActionMessage -> pcb_act_Message +message_help -> pcb_acth_Message +message_syntax -> pcb_acts_Message +ActionMode -> pcb_act_Mode +mode_help -> pcb_acth_Mode +mode_syntax -> pcb_acts_Mode +ActionToggleHideName -> pcb_act_ToggleHideName +togglehidename_help -> pcb_acth_ToggleHideName +togglehidename_syntax -> pcb_acts_ToggleHideName +ActionSetSame -> pcb_act_SetSame +setsame_help -> pcb_acth_SetSame +setsame_syntax -> pcb_acts_SetSame +ActionRouteStyle -> pcb_act_RouteStyle +routestyle_help -> pcb_acth_RouteStyle +routestyle_syntax -> pcb_acts_RouteStyle +ActionCreateMenu -> pcb_act_CreateMenu +createmenu_help -> pcb_acth_CreateMenu +createmenu_syntax -> pcb_acts_CreateMenu +ActionRemoveMenu -> pcb_act_RemoveMenu +removemenu_help -> pcb_acth_RemoveMenu +removemenu_syntax -> pcb_acts_RemoveMenu +ActionSwitchHID -> pcb_act_SwitchHID +switchhid_help -> pcb_acth_SwitchHID +switchhid_syntax -> pcb_acts_SwitchHID +ActionPrintActions -> pcb_act_PrintActions +printactions_help -> pcb_acth_PrintActions +printactions_syntax -> pcb_acts_PrintActions +ActionDumpActions -> pcb_act_DumpActions +dumpactions_help -> pcb_acth_DumpActions +dumpactions_syntax -> pcb_acts_DumpActions +ActionPrintUsage -> pcb_act_PrintUsage +printusage_help -> pcb_acth_PrintUsage +printusage_syntax -> pcb_acts_PrintUsage +ActionPrintVersion -> pcb_act_PrintVersion +printversion_help -> pcb_acth_PrintVersion +printversion_syntax -> pcb_acts_PrintVersion +ActionPrintCopyright -> pcb_act_PrintCopyright +printcopyright_help -> pcb_acth_PrintCopyright +printcopyright_syntax -> pcb_acts_PrintCopyright +ActionPrintPaths -> pcb_act_PrintPaths +printpaths_help -> pcb_acth_PrintPaths +printpaths_syntax -> pcb_acts_PrintPaths +ActionNetlist -> pcb_act_Netlist +netlist_help -> pcb_acth_Netlist +netlist_syntax -> pcb_acts_Netlist +ActionNetlist -> pcb_act_Netlist +netlist_help -> pcb_acth_Netlist +netlist_syntax -> pcb_acts_Netlist +ActionAttributes -> pcb_act_Attributes +attributes_help -> pcb_acth_Attributes +attributes_syntax -> pcb_acts_Attributes +ActionDisperseElements -> pcb_act_DisperseElements +disperseelements_help -> pcb_acth_DisperseElements +disperseelements_syntax -> pcb_acts_DisperseElements +ActionFlip -> pcb_act_Flip +flip_help -> pcb_acth_Flip +flip_syntax -> pcb_acts_Flip +ActionListRotations -> pcb_act_ListRotations +listrotations_help -> pcb_acth_ListRotations +listrotations_syntax -> pcb_acts_ListRotations +ActionMoveObject -> pcb_act_MoveObject +moveobject_help -> pcb_acth_MoveObject +moveobject_syntax -> pcb_acts_MoveObject +ActionMoveToCurrentLayer -> pcb_act_MoveToCurrentLayer +movetocurrentlayer_help -> pcb_acth_MoveToCurrentLayer +movetocurrentlayer_syntax -> pcb_acts_MoveToCurrentLayer +ActionElementList -> pcb_act_ElementList +elementlist_help -> pcb_acth_ElementList +elementlist_syntax -> pcb_acts_ElementList +ActionElementSetAttr -> pcb_act_ElementSetAttr +elementsetattr_help -> pcb_acth_ElementSetAttr +elementsetattr_syntax -> pcb_acts_ElementSetAttr +ActionRipUp -> pcb_act_RipUp +ripup_help -> pcb_acth_RipUp +ripup_syntax -> pcb_acts_RipUp +ActionMinMaskGap -> pcb_act_MinMaskGap +minmaskgap_help -> pcb_acth_MinMaskGap +minmaskgap_syntax -> pcb_acts_MinMaskGap +ActionMinClearGap -> pcb_act_MinClearGap +mincleargap_help -> pcb_acth_MinClearGap +mincleargap_syntax -> pcb_acts_MinClearGap +MoveLayerAction -> pcb_act_MoveLayerAction +movelayeraction_help -> pcb_acth_MoveLayerAction +movelayeraction_syntax -> pcb_acts_MoveLayerAction +Action_fp_rehash -> pcb_act__fp_rehash +_fp_rehash_help -> pcb_acth__fp_rehash +_fp_rehash_syntax -> pcb_acts__fp_rehash +ActionMorphPolygon -> pcb_act_MorphPolygon +morphpolygon_help -> pcb_acth_MorphPolygon +morphpolygon_syntax -> pcb_acts_MorphPolygon +ActionPolygon -> pcb_act_Polygon +polygon_help -> pcb_acth_Polygon +polygon_syntax -> pcb_acts_Polygon +ActionAddRats -> pcb_act_AddRats +addrats_help -> pcb_acth_AddRats +addrats_syntax -> pcb_acts_AddRats +ActionConnection -> pcb_act_Connection +connection_help -> pcb_acth_Connection +connection_syntax -> pcb_acts_Connection +ActionDeleteRats -> pcb_act_DeleteRats +deleterats_help -> pcb_acth_DeleteRats +deleterats_syntax -> pcb_acts_DeleteRats +ActionDelete -> pcb_act_Delete +delete_help -> pcb_acth_Delete +delete_syntax -> pcb_acts_Delete +ActionRemoveSelected -> pcb_act_RemoveSelected +removeselected_help -> pcb_acth_RemoveSelected +removeselected_syntax -> pcb_acts_RemoveSelected +ActionSelect -> pcb_act_Select +select_help -> pcb_acth_Select +select_syntax -> pcb_acts_Select +ActionUnselect -> pcb_act_Unselect +unselect_help -> pcb_acth_Unselect +unselect_syntax -> pcb_acts_Unselect +ActionAtomic -> pcb_act_Atomic +atomic_help -> pcb_acth_Atomic +atomic_syntax -> pcb_acts_Atomic +ActionUndo -> pcb_act_Undo +undo_help -> pcb_acth_Undo +undo_syntax -> pcb_acts_Undo +ActionRedo -> pcb_act_Redo +redo_help -> pcb_acth_Redo +redo_syntax -> pcb_acts_Redo +ActionReplaceFootprint -> pcb_act_ReplaceFootprint +replacefootprint_help -> pcb_acth_ReplaceFootprint +replacefootprint_syntax -> pcb_acts_ReplaceFootprint +ActionSavePatch -> pcb_act_SavePatch +savepatch_help -> pcb_acth_SavePatch +savepatch_syntax -> pcb_acts_SavePatch +ActionManagePlugins -> pcb_act_ManagePlugins +manageplugins_help -> pcb_acth_ManagePlugins +manageplugins_syntax -> pcb_acts_ManagePlugins +ActionConf -> pcb_act_Conf +conf_help -> pcb_acth_Conf +conf_syntax -> pcb_acts_Conf +ActionGetStyle -> pcb_act_GetStyle +getstyle_help -> pcb_acth_GetStyle +getstyle_syntax -> pcb_acts_GetStyle +ActionChkMode -> pcb_act_ChkMode +chkmode_help -> pcb_acth_ChkMode +chkmode_syntax -> pcb_acts_ChkMode +ActionChkGridSize -> pcb_act_ChkGridSize +chkgridsize_help -> pcb_acth_ChkGridSize +chkgridsize_syntax -> pcb_acts_ChkGridSize +ActionChkElementName -> pcb_act_ChkElementName +chkelementname_help -> pcb_acth_ChkElementName +chkelementname_syntax -> pcb_acts_ChkElementName +ActionChkGridUnits -> pcb_act_ChkGridUnits +chkgridunits_help -> pcb_acth_ChkGridUnits +chkgridunits_syntax -> pcb_acts_ChkGridUnits +ActionChkBuffer -> pcb_act_ChkBuffer +chkbuffer_help -> pcb_acth_ChkBuffer +chkbuffer_syntax -> pcb_acts_ChkBuffer +ActionFreeRotateBuffer -> pcb_act_FreeRotateBuffer +freerotatebuffer_help -> pcb_acth_FreeRotateBuffer +freerotatebuffer_syntax -> pcb_acts_FreeRotateBuffer +ActionPasteBuffer -> pcb_act_PasteBuffer +pastebuffer_help -> pcb_acth_PasteBuffer +pastebuffer_syntax -> pcb_acts_PasteBuffer +ActionDumpLibrary -> pcb_act_DumpLibrary +dumplibrary_help -> pcb_acth_DumpLibrary +dumplibrary_syntax -> pcb_acts_DumpLibrary +ActionBell -> pcb_act_Bell +bell_help -> pcb_acth_Bell +bell_syntax -> pcb_acts_Bell +ActionToggleVendor -> pcb_act_ToggleVendor +togglevendor_help -> pcb_acth_ToggleVendor +togglevendor_syntax -> pcb_acts_ToggleVendor +ActionEnableVendor -> pcb_act_EnableVendor +enablevendor_help -> pcb_acth_EnableVendor +enablevendor_syntax -> pcb_acts_EnableVendor +ActionDisableVendor -> pcb_act_DisableVendor +disablevendor_help -> pcb_acth_DisableVendor +disablevendor_syntax -> pcb_acts_DisableVendor +ActionImport -> pcb_act_Import +import_help -> pcb_acth_Import +import_syntax -> pcb_acts_Import +ActionLoadhypFrom -> pcb_act_LoadhypFrom +loadhypfrom_help -> pcb_acth_LoadhypFrom +loadhypfrom_syntax -> pcb_acts_LoadhypFrom +ActionRenumber -> pcb_act_Renumber +renumber_help -> pcb_acth_Renumber +renumber_syntax -> pcb_acts_Renumber +ActionRenumberBlock -> pcb_act_RenumberBlock +renumberblock_help -> pcb_acth_RenumberBlock +renumberblock_syntax -> pcb_acts_RenumberBlock +ActionRenumberBuffer -> pcb_act_RenumberBuffer +renumberbuffer_help -> pcb_acth_RenumberBuffer +renumberbuffer_syntax -> pcb_acts_RenumberBuffer +ActionLoadDsnFrom -> pcb_act_LoadDsnFrom +loaddsnfrom_help -> pcb_acth_LoadDsnFrom +loaddsnfrom_syntax -> pcb_acts_LoadDsnFrom +ActionDumpConf -> pcb_act_DumpConf +dumpconf_help -> pcb_acth_DumpConf +dumpconf_syntax -> pcb_acts_DumpConf +ActionDumpLayers -> pcb_act_DumpLayers +dumplayers_help -> pcb_acth_DumpLayers +dumplayers_syntax -> pcb_acts_DumpLayers +ActionEvalConf -> pcb_act_EvalConf +evalconf_help -> pcb_acth_EvalConf +evalconf_syntax -> pcb_acts_EvalConf +ActionPSCalib -> pcb_act_PSCalib +pscalib_help -> pcb_acth_PSCalib +pscalib_syntax -> pcb_acts_PSCalib +ActionApplyVendor -> pcb_act_ApplyVendor +applyvendor_help -> pcb_acth_ApplyVendor +applyvendor_syntax -> pcb_acts_ApplyVendor +ActionUnloadVendor -> pcb_act_UnloadVendor +unloadvendor_help -> pcb_acth_UnloadVendor +unloadvendor_syntax -> pcb_acts_UnloadVendor +ActionLoadVendorFrom -> pcb_act_LoadVendorFrom +loadvendorfrom_help -> pcb_acth_LoadVendorFrom +loadvendorfrom_syntax -> pcb_acts_LoadVendorFrom +ActionAutoRoute -> pcb_act_AutoRoute +autoroute_help -> pcb_acth_AutoRoute +autoroute_syntax -> pcb_acts_AutoRoute +GlobalPuller -> pcb_act_GlobalPuller +globalpuller_help -> pcb_acth_GlobalPuller +globalpuller_syntax -> pcb_acts_GlobalPuller +Puller -> pcb_act_Puller +puller_help -> pcb_acth_Puller +puller_syntax -> pcb_acts_Puller +ActionAutoPlaceSelected -> pcb_act_AutoPlaceSelected +autoplaceselected_help -> pcb_acth_AutoPlaceSelected +autoplaceselected_syntax -> pcb_acts_AutoPlaceSelected +ActionDJopt -> pcb_act_DJopt +djopt_help -> pcb_acth_DJopt +djopt_syntax -> pcb_acts_DJopt +h_str -> pcb_hash_str +h_coordox -> pcb_hash_element_ox +h_coordoy -> pcb_hash_element_oy +h_coord -> pcb_hash_coord +pcb_buffer_swap -> pcb_buffer_flip_side +pcb_swap_buffers -> pcb_buffers_flip_side +LAYER_IS_PCB_EMPTY -> PCB_LAYER_IS_EMPTY +LAYER_IS_PCB_EMPTY -> PCB_LAYER_IS_EMPTY +IsLayerEmpty -> pcb_layer_is_empty_ +IsLayerNumEmpty -> pcb_layer_is_empty +IsLayerGroupEmpty -> pcb_is_layergrp_empty +ParseGroupString -> pcb_layer_parse_group_string +GetLayerNumber -> pcb_layer_id +GetGroupOfLayer -> pcb_layer_get_group +GetLayerGroupNumberByPointer -> pcb_layer_get_group_ +GetLayerGroupNumberByNumber -> pcb_layer_get_group +IsPasteEmpty -> pcb_layer_is_paste_empty +SOLDER_LAYER -> PCB_SOLDER_SIDE +COMPONENT_LAYER -> PCB_COMPONENT_SIDE +LayerStringToLayerStack -> pcb_layervis_parse_string +ChangeGroupVisibility -> pcb_layervis_change_group_vis +ResetStackAndVisibility -> pcb_layervis_reset_stack +SaveStackAndVisibility -> pcb_layervis_save_stack +RestoreStackAndVisibility -> pcb_layervis_restore_stack Index: trunk/doc/developer/src/Makefile =================================================================== --- trunk/doc/developer/src/Makefile (nonexistent) +++ trunk/doc/developer/src/Makefile (revision 5594) @@ -0,0 +1,2 @@ +../data1.png: data1.dot + dot -Tpng $^ > $@ Index: trunk/doc/developer/src/data1.dot =================================================================== --- trunk/doc/developer/src/data1.dot (nonexistent) +++ trunk/doc/developer/src/data1.dot (revision 5594) @@ -0,0 +1,59 @@ +digraph pcb_data { + PCBType_misc [label="misc fields:\nID\nName\nFileName\ncolors\ndrc settings\ncursor coords\ngrid\nlayergroups\nroute styles\n..."] + PCBType_flags [label="flags:\nChanged\nViaOn (vias drawn?)\n..."] + pcb_board_t -> PCBType_misc + pcb_board_t -> PCBType_flags + pcb_board_t -> pcb_data_t + pcb_board_t [shape=box] + + PCB [label="extern pcb_board_t PCB\nglobal variable\nholding the current\nboard" shape=diamond] + PCB -> pcb_board_t + + Buffers [label="extern pcb_buffer_t Buffers[]\nglobal variable holding\nall paste buffers" shape=diamond] + Buffers -> pcb_buffer_t + + BufferType_misc [label="misc fields:\nbounding box\noffset"] + pcb_buffer_t -> BufferType_misc + pcb_buffer_t -> pcb_data_t + pcb_buffer_t [shape=box] + + DataType_lists [label="layer-independent lists:\nrats\nvias\nelements"] + DataType_rtrees [label="layer-independent rtrees"] + DataType_LayerN [label="LayerN: number of\nlayers in use"] + DataType_layers [label="an array of layers"] + DataType_misc [label="misc fields"] + + pcb_data_t -> DataType_misc + pcb_data_t -> DataType_LayerN + pcb_data_t -> DataType_layers + pcb_data_t -> DataType_lists + pcb_data_t -> DataType_rtrees + pcb_data_t [shape=box] + + DataType_layers -> pcb_layer_t + + + LayerType_lines [label="list and rtree of lines"] + LayerType_arcs [label="list and rtree of arcs"] + LayerType_texts [label="list and rtree of text objects"] + LayerType_polygons [label="list and rtree of polygons"] + LayerType_misc [label="misc fields:\nflags\ncolors"] + + pcb_layer_t -> LayerType_misc + pcb_layer_t -> LayerType_lines + pcb_layer_t -> LayerType_arcs + pcb_layer_t -> LayerType_texts + pcb_layer_t -> LayerType_polygons + pcb_layer_t [shape=box] + + subgraph "cluster_1" { + label="LEGEND" + style=filled + bgcolor=grey + round [label="round:\nstruct field"] + struct [label="box:\nstruct" shape=box] + diamond [label="diamond:\nglobal variable" shape=diamond] + } + + LayerType_misc -> struct [style=invis] +} Index: trunk/doc/devlog/20150731a_menu.html =================================================================== --- trunk/doc/devlog/20150731a_menu.html (nonexistent) +++ trunk/doc/devlog/20150731a_menu.html (revision 5594) @@ -0,0 +1,59 @@ + + +

pcb-rnd devlog

+

Dynamic menus

+

Background

+Before integrating gpmi scripting, pcb-rnd needs to be prepared to +interface with the scripts. The engine is pretty much ready since ages: +the action interface is ideal for scripts to register their actions or +execute existing actions. This also means the command line and batch +UI are instantly connected with scripts. +

+The only largely visible remaining portion is the GUI. pcb-gpmi supports +building dialog boxes using the current HID (so called attribute dialogs, +originally invented for exporter settings) and calling some simpler predefined +dialogs like a progress bar or alert. +

+What's really missing is a way to create new menus on the fly. The user +loads a script and the script makes up a menu with submenus, all bound to +the proper actions. +

+This introduces a nice dilemma, tho: there is a real cool menu configuration +file that makes the user able to reconfigure the menu system, hot keys, tool +tips and whatnot (I wish more applications had this feature!). What if a script +comes in and trolls the whole thing creating random menus at surprising +places in the menu system? How the user can control what the script could do +with his preciously crafted menu setup tailored to his own preferences? +

+I believe in sharp tools and careful users. I indeed plan to allow scripts to +do whatever they want with the menu system but I invent some conventions too. +As long as scripts stick to these conventions, the user retain control over +the menu layout. + +

How it works

+ +PCB reads *menu.res and builds the gui on startup; the menu system is +static after that point. pcb-rnd does the same on startup but also +stores all menus (referenced by their paths, like "/File/Save as") in a +hash table. Later on a call to a new hid function (create_menu()) can +create new menus or submenus, extending the menu tree at any point. +

+When a new menu "/File/foo" is created, using the hash create_menu() +finds out that /File already exists and doesn't create it but use the +existing widget from the hash. This means if the user creates menus from +the res file that are also created by the script, the res file sort of +overrides the script's later actions as all those menus will already exist +by the time the script tries to create them. +

+And here comes the conventions part: +

+ +As long as plugins and scripts stick to this convention, the user can +create all the menus for all the plugins and scripts in advance. Stock +menu res files will have the /Plugin menu at least, so its place is fixed. + + Index: trunk/doc/devlog/20150731b_gtk.html =================================================================== --- trunk/doc/devlog/20150731b_gtk.html (nonexistent) +++ trunk/doc/devlog/20150731b_gtk.html (revision 5594) @@ -0,0 +1,36 @@ + + +

pcb-rnd devlog

+

dynamic gtk menus

+As described in the previous post, +pcb-rnd will feature dynamic menus. I first implemented this in the +gtk hid. +

+It turned out gtk was way too OOP for my taste1. It took about 6 +hours total, to implement and debug the feature. (As a comparison, it +took about 90 minutes to make the research related to +the resource structs in PCB and implement the HID modifications for +the new hid command). The trickiest part was +to figure the need of calling a show() on the menubar after adding +the new items. +

+When I didn't have that, only plain action menu/submenus showed up +(in already existing menu/ widgets), but +new (main) menus and menu/submenu/submenus didn't. After many hours of gdb +sessions I finally made sure (by printing all the widgets to stderr +recursively) that: +

+Then I also printed allocated dimensions and coordinates - but the values +were misleading. Finally I figured there was different flags like realization +and visibility, so printed them too. This revealed that all my new menus were +there in an invisible state. +
+

Footnotes

+1: not because of the show() call, but because of the way objects +are stored in memory: too many generic pointers casted forth and back, makes it +really hard to print all properties of a menu item (including its label) +with gdb. Index: trunk/doc/devlog/20150801a_events.html =================================================================== --- trunk/doc/devlog/20150801a_events.html (nonexistent) +++ trunk/doc/devlog/20150801a_events.html (revision 5594) @@ -0,0 +1,22 @@ + + +

pcb-rnd devlog

+

events

+PCB has a nice action infrastructure: most user actions are +implemented in smallish functions taking (int argc, char *argv[]). Menu +items, hotkeys, the command line and batch processing just call these +actions. This is the user->pcb_core direction of commands. +

+Before adding scripting to pcb-rnd, the other direction (pcb_core->user) has +to be implemented: an event infrastructure. Random parts of the core +or the HID code will yield events using a simple vararg event() function. +Other parts of PCB, especially plugins, can bind (sign up to) events with +function pointers. When an event is triggered, all functions signed up to +the event are called (in random order). +

+Passing arguments to events is similar to the arguments of actions, except +argv[] is not a char *[], but an event_arg_t *[]. event_arg_t has an enum +field for argument type and an union for the argument value. This means the +API is binary: integers are passed as integers, not as strings. + + Index: trunk/doc/devlog/20150803a_scriptig.html =================================================================== --- trunk/doc/devlog/20150803a_scriptig.html (nonexistent) +++ trunk/doc/devlog/20150803a_scriptig.html (revision 5594) @@ -0,0 +1,36 @@ + + +

pcb-rnd devlog

+

scripting

+Most of the infrastructure for a scriptable pcb had been there in pcb-gpmi. +I had also finished some gpmi cleanup and pcb +(menu and + events ) subprojects last week. +These made it easier to get to reach the current status after a weekend +coding marathon: + +

+My example scripts are written in awk, lua and tcl +at this point, but gpmi supports 7 other languages +(scheme, stutter (lisp), pascal, perl +php, python, ruby) which are also available in +pcb-rnd. + Index: trunk/doc/devlog/20150816a_scriptig.html =================================================================== --- trunk/doc/devlog/20150816a_scriptig.html (nonexistent) +++ trunk/doc/devlog/20150816a_scriptig.html (revision 5594) @@ -0,0 +1,28 @@ + + +

pcb-rnd devlog

+

scripting, 2

+I've been working on the documentation for pcb-rnd scripting lately. +Proof reading and comments would be appreciated. The documents are +work-in-progress. +

+I have a Rosetta stone +of examples demonstrating how to write simple scripts. +It doesn't explain how the system works, but shows easy-to-understand +practical examples. Useful for those who like learn by doing and look up +the "theoretical" background only after seeing things in practice. +

+Another document, the +scripting intro focuses on explaining how things are built up. This +one is useful for those who first want to understand the design and then +look at how to do things in practice. +

+As a next step I plan to reorganize the package documentation and split +them all into a high level "what's the concept" doc and a low level +reference manual. +

+I also plan to improve the links between the docs and write more rosetta +examples. I plan to have a few more all-language examples on the most +basic things. The more complex examples would be written in awk, lua and +maybe ruby. + Index: trunk/doc/devlog/20150820a_dimensions.html =================================================================== --- trunk/doc/devlog/20150820a_dimensions.html (nonexistent) +++ trunk/doc/devlog/20150820a_dimensions.html (revision 5594) @@ -0,0 +1,24 @@ + + +

pcb-rnd devlog

+

fp2anim dimensions

+After attacking the qfn()/qfp() parametric footprint problem today, +I realized fp2anim lacked a very important feature: dimension lines. +The footprint being generated is to match the datasheet. Checking the match +requires visible dimensions. +

+The new feature of fp2anim is to optionally display custom dimensions on +the preview. Generator scripts print #dimension comments in the footprint +file (not breaking the file format). The generator passes on a dimension +name along with the value. As a first attempt my conventions are: +

+ +

fp2anim vector font

+While working on the dimensions, I realized I had to switch to vector fonts: +the built-in pixel font of animator can not be rotated. The size of a vector +font text can be calculated, which also enables fp2anim to optionally place +semi-transparent bars behind the text to make it more visible on dark background +(like pads). Index: trunk/doc/devlog/20150820b_qf.html =================================================================== --- trunk/doc/devlog/20150820b_qf.html (nonexistent) +++ trunk/doc/devlog/20150820b_qf.html (revision 5594) @@ -0,0 +1,27 @@ + + +

pcb-rnd devlog

+

qf()

+The next group of footprints I decided to generate are qfn(), tqfp(), lqfp(). +The generic set of rules for these footprints is: + + +

low level flexibility vs. high level comfort

+qf() currently has 14 arguments. It is flexible enough to generate qfn, tqfp, +lqfp, and anything similar I've seen in the package datasheet of a major +vendor. However, it is not straight forward to convert datasheet tables +into qf() parameters. +

+On the other hand, in practice we need qfn() and tqfp(), which are special +cases of qf(). To nail the common use cases, qfn() and tqfp() narrows down +the number of parameters to 3..4. Even better, these parameters are exactly +those that are in the name of a typical QFN or TQFP footprint or in the first +few lines of the dimensions table. I call these scripts frontends to qf(). +

+This makes the common footprints very easy to produce using frontends while +leaves a (bit more complicated) plan B, qf(), for special cases. Index: trunk/doc/devlog/20150821a_parametric_requirements.html =================================================================== --- trunk/doc/devlog/20150821a_parametric_requirements.html (nonexistent) +++ trunk/doc/devlog/20150821a_parametric_requirements.html (revision 5594) @@ -0,0 +1,32 @@ + + +

pcb-rnd devlog

+

requirements for parametric footprint generation

+ +It's appealing to write parametric footprint generators for new footprint +families: invest some time once, and have a tool that can spit out +dozens of footprints. However, it is not always worth having a generator +instead of static footprints. The minimal requirements for a generator are: + + Index: trunk/doc/devlog/20150830a_fork_faq.html =================================================================== --- trunk/doc/devlog/20150830a_fork_faq.html (nonexistent) +++ trunk/doc/devlog/20150830a_fork_faq.html (revision 5594) @@ -0,0 +1,257 @@ + + +

pcb-rnd devlog

+ +

Fork FAQ

+ +This document contains my short answers to questions commonly popping up +in endless flamewars on the geda mailing list. The purpose of this +document is not to convince anyone about any of the questions, only +to save me some time typing the same answers when someone asks me +one these questions for the 100th time. As I don't want to convince you +that my answers are the best ones, please don't try to convince me that +they are bad. Been there, done that, never worked in either way: e.g. +I never convinced any git fanboy to switch to svn, and they never +convince me to switch to git. + +

1. Why did you fork?

+ +

1.1. Fragmentation is bad, your fork is harmful!

+I agree that fragmentation is bad. I believe the same aspects of +the current project management and especially the choice of VCS inevitably +leads to forks (just look at how many git forks are out there!). Such +fragmentation of developer and user resources may be bad for a project. +However, these decisions are not mine: the project is set up like +that, I can't change it +

+My fork is just a fork, just like any of the other forks. My fork happens to +be in an svn repository. I don't think it changes anything important from the +mainline's point of view. + +

1.2. ... but how will you get all these merged with mainline?

+I won't. I haven't really used the official, current mainline since like +2011. I don't really care in what directions it evolves or whether it +takes features, code or ideas from pcb-rnd or not. + +

1.3. ... but you are in the best position for a merge!

+I don't think so. I know my changes, but I don't know the changes happened +in the mainline since ages. I am also not efficient with git. It wouldn't +take me any less time than for mainline developers. Also please read point 1.2.: +I have no motivation in spending any time on a merge. + +

1.4. Ok then, but you won't have too many users.

+Fine. My main intention was to produce a pcb editor for my own use. I am +happy if it's also useful for others, so I publish it. Having users +may increase code quality - but other than that, I don't get paid for having +more users, the project doesn't die if I code it alone, so I am not worried +about this. +

+Update (Aug 2016): an active user/contributor community is forming +around pcb-rnd. It is not a one-man-show anymore. + +

1.5. I'd like to merge something from pcb-rnd to mainline

+Go ahead. I can help you by explaining my code. I won't generate +patches, make changes to get my code compatible with the mainline or +test how it performs in mainline versions. + +

1.6. I'd like to merge something from mainline to pcb-rnd

+If the feature is in line with the goals of pcb-rnd, fine, I'll give +you svn commit access from day 0. + +

1.7. Would you abandon the development of pcb-rnd and join the mainline, if...

+Unlikely. There are many things I have in pcb-rnd which I believe won't ever +happen in mainline. There are a few which I find critical: if I'd need to +give up any single item from this list, that would be a deal-breaker for me: + + + +

1.8. Would you join the development of gschem?

+Unlikely. See point 1.7. Gschem is not aiming to a C++ transition AFAIK, +but has a lot of scheme. I don't consider joining or contributing to +gschem until those points listed in 1.7. are fixed and a new scheme +policy is introduced. The new policy should be: "from now on +do not write new code in scheme, use C; while making changes and fixes, +convert affected scheme code to C. Long term, explicit plan: convert all +scheme code to C and remove the guile dependency." +

+I don't expect any of this to happen. +

+Update (Aug 2016): Instead, I'll launch cschem . + + +

2. git: did you know...

+ +Preface: I don't try to convince you not to use git in your project; in +return, please don't try to convince me I should use git in mine. + +

2.1. ... that there was an svn frontend to git?

+Yes. 2/3 of my problems with git and DVCS in general are not of technical +nature. I know the concepts of DVCS and I find them suboptimal in +case of small teams. A different UI or a good document won't help in that. + +

2.2. ... that there was this great document about git?

+See 2.1. + +

2.3. ... that DVCS is the future, anything centralized is bad, svn is obsolete?

+These are not facts, but slogans I don't believe in. + +

2.4. What if someone has to develop offline for long?

+In the 21th century, when we have cheap mobile internet even in eastern +Europe? + +

2.5. But feature X is harder with svn!

+Almost all those features are bad for team work in my experience. They +are not even needed. Yes, some aspects of the development have to be +done differently without those - but this is good for the project. + +

2.6. But there are no local repositories and you have to commit unfinished stuff and worry if anything breaks! And branching is hard

+This is the point. I do not branch. I do not attempt to work offline for long, +whatever technical support the VCS may provide for that. I try to work in +a team, on a common code base. +

+I commit small things. I make sure I do a big transition using +these small commits in a way that the code stays compilable in between any +two commits. It rarely breaks trunk/ for longer than a few minutes. I +need a real branch once a decade. + +

2.7. But that's extra effort and makes life harder!

+Yes and no. It's certainly harder to design and carry out a big +reorganization in small steps. This is an extra cost. However, the +benefits outweight this: everyone working in the same repo, +other developers see and comment what you are working on, if done right, +merging is nearly never needed and conflicts are as rare as bugfree +release of a multi-million line proprietary software. + +

2.8. I don't agree with any of this, git is better!

+Cool, so go on using git. I didn't try to convince you not to, I just +explained why I won't. + +

3. opengl

+ +

3.1. But I need opengl!

+Use the mainline then. Or contribute the code for sane opengl support +in pcb-rnd. +

+Update (Aug 2016): GUI HIDs are plugins now, multiple GUIs can +be compiled and chosen run-time. Default GUI is a runtime configuration too. +All we need to have an opengl GUI HID now is a gl-capable volunteer. + +

3.2. ... good, then please make that opengl hid!

+No, thanks. I don't need it, I wouldn't use it, there's no point in spending +my time on it. If you need it, I invite you to do it. +

+Update (Aug 2016): I can do the build system and plugin administration +part for you. + +

3.3. Did you know that opengl can be turned off in mainline?

+Yes. If I have a fork, I want its defaults to reflect my preferences. + +

3.4. But transparent renders are so good on a board with many layers!

+Not for me: transparency made even a 2 layer board cryptic when I tried. See +3.1. + + +

4. programming languages, file formats

+ +

4.1. switch to C++, it is so much better

+Nope. I prefer C. + +

4.2. but pcb-rnd doesn't compile with a C++ compiled

+Correct: pcb-rnd is written in C. It also doesn't compile with a Pascal +compiler. + +

4.3. but mainline already invested in preparing a C++ transition

+Good for them. If I didn't have a fork, I'd fork the day when the first +C++ class is committed. + +

4.4. we need SQL for the file format

+No, we don't. I prefer human readable text formats. No, converters won't +solve that. No, I don't care if python has support for loading SQL files. +

+Update (Aug 2016): the file format is a replacable plugin now; +it's even possible to have multiple alternative formats active in the same +time. It's up to you to implement your format in a plugin. + +

4.3. we need to switch to xml/json (or python or perl arrays)

+No, we don't need to. +

+Update (Aug 2016): ... unless you implement it in a plugin, see point 4.4. + +

4.4. ... but they are easier to parse because of existing libs

+Yup, but in any real life task that part of the parsing is like 5%. The +rest 95% needs to be programmed anyway. The costs of such a file format change +is not justified by this minor gain. + +

4.5. ... but the current file format doesn't support feature X

+ +True. And that's because the internal model (the in-core representation +and all the code handling that) doesn't support the feature either. +Changing the file format won't help that. It's similar to point 4.4.: 95% +of the effort is needed to get the code to support the feature, and by that +time the cost of getting it into the file format is very small. Costs +are not justified. + +

+Update (Aug 2016): long term the new primary file format will be +lihata to overcome the above limitations. Later on the internal representation +may change too. + +

4.6. ... but I can't build a database of the current lib

+Too bad. Either figure how to do it, or just don't do it. pcb-rnd +offers scripting, even in languages that have SQL support. In theory +it wouldn't be that hard to write scripts running in PCB manipulating +the buffer or even the in-core footprints on one end and connecting +an SQL database on the other end. + + +

5. scconfig, autotools, build systems

+ +

5.1. scconfig doesn't support feature X that autotools does

+Are you sure? Maybe it does, just uses a different syntax. If not, did +you try to send me a feature request? + +

5.2. scconfig's syntax is different

+Yes. Scconfig has a totally different internal model thus the UI differs +too. Same as vim has a different UI than emacs, while they are both text +editors and the two communities are not trying too hard to unify the UIs. + +

5.3. But ./configure has to have the same UI as autotools

+False. + +

5.4. Most people know autotools, there are merits in supporting the same features or UI

+I do realize that. I've been working on scconfig since 2008. I've invested +a lot of time in it. Believe me, I did think it over before I decided that +the benefits would overweight the drawbacks of developing/using a custom +config/build system. + +

5.5. But autotools is so much better!

+No, it isn't. My experience is that with random open source projects +on anything different from Linux, modern BSD, and sometimes windows, it +just breaks at least 8 times out of 10. Try it once on IRIX or minix. + +

5.6. So why don't you rather fix autotools?

+I believe there are multiple design problems in autotools and most of +the practical problems I faced when using it were directly caused by those. +In a sense, I did fix these design problems by using a different design. +The different design is called scconfig and it was much easier to +write it from scratch. + +

5.7. But scconfig doesn't do cross compilation!

+False. It does. It's been supported since May 2008. It's been added +about 1.5 months after the very first file. +

+Update (Aug 2016): as a practical example, windows .exe has +been cross-compiled on a Linux box. + +

5.8. I just don't like scconfig.

+If you have something particular that makes you dislike scconfig, +a missing feature for example, please let me know. +

+Else maybe you don't like using anything else than autotools. It's your +choice; mine is that I do keep on using scconfig in my projects. + Index: trunk/doc/devlog/20150830b_back_ann.html =================================================================== --- trunk/doc/devlog/20150830b_back_ann.html (nonexistent) +++ trunk/doc/devlog/20150830b_back_ann.html (revision 5594) @@ -0,0 +1,304 @@ + + +

pcb-rnd devlog

+ +

back annotation

+ +

netlists, annotations

+ +Pcb-rnd (and mainline pcb) maintains a netlist as part of the design. Pcb +doesn't modify the netlist. The netlist is imported from an external source, +typically from gschem. This process is called forward annotation. +

+Sometimes there are a set of connections which contain pin pairs that could +be swapped. For example the data lines of an external parallel SRAM interface +to an MCU: it doesn't matter if data bit 1 at the MCU is wired to data bit +1 or 5 of the SRAM, as there is an 1:1 mapping and no one else is using the +same bus wires. In this case connections should be swapped during pcb routing +and annotated back to gschem so that the schematics can be updated. Both +paths are illustrated below. +

+annotation paths +

+Forward annotation passes on complete netlists along arrows forward1 and +forward2. Back annotation would pass back netlists, changes or modification +requests on the back1, back2 path. Gnetlist takes sch files to extract +and build a netlist in whatever format the receiver needs. There should be a +glue layer, called foo on the drawing, that does the reverse: receives +whatever format the sender has and generates something that gschem will +understand. + +

Support in pcb-rnd: core

+Pcb-rnd gets a complete netlist. If the user could change the netlist directly, +there should be some sort of diff tool in foo that can explain the +changes to gschem, or a diff tool in gschem. What is worse, forward annotation +happens much more often than back annotation and pcb-rnd would need to be able +to merge a new netlist with local changes. The simple "gsch2pcb overwrites the +netlist in pcb from whatever gnetlist produced" approach would not work. +

+An alternative is to keep the netlist as-is, and maintain a separate list of +changes. The form proposed hereby is a table of "operation,pinID,net" or +"operation,args...". Netlist operation is one of "del_conn", "add_conn" and "net_info". The table is called the netlist patch. +

+For example assume two components with pins A1, A2 and B1, B2, with connections +n1=A1-B1 and n2=A2-B2. While routing the designer decides changing them to +n1=A1-B2 and n2=A2-B1 would be easier and is acceptable by the design. The +table of changes would contain this: + +
op pinID net +
del_conn B1 n1 +
del_conn B2 n2 +
add_conn B2 n1 +
add_conn B1 n2 +
+The first two lines would remove pins B1 and B2 from n1 and n2. The last +two would put them back, swapped. New nets could be created or unused nets +could be removed using the add_net and del_net commands that have empty pinID. +The table is ordered, rows are strictly executed from top to bottom. +

+Pcb-rnd would store this table in memory. When some code calls the netlist +code to find out the members of a net, or which net a given pin is connected to, +after running the original netlist code, the result would be adjusted by the table. +

+The table would be normalized after operations. For example: + +
op pinID net +
del_conn B1 n1 +
add_conn B1 n2 +
add_conn B1 n3 +
del_conn B1 n2 +
+would be reduced to + +
op pinID net +
del_conn B1 n1 +
add_conn B1 n3 +
+Simple linear crawls on the table seems sufficient: it is expected that +pcb designers will make netlist modifications rarely and they will back +annotate them ASAP. In extreme cases there may be 64 bit wide bus systems that +need total reordering; even a 4 such reorders will introduce about 1024 items +on the list which seems not too big for O(1) algorithms. See section TODO +for better approaches. +

+Pcb-rnd would save the normalized table in the pcb file in a new section. +Upon a netlist change in pcb (import/load netlist or load the pcb), pcb-rnd +would check each row of the table: it is easy to decide whether that row +has been implemented in the netlist or not. Obsolete rows of the table would +be deleted. +

+A corner case is when B1 is removed from n1 and then added to n2 by the table, +while a new forward annotation removes B1 from n1 and adds it to n3. In this +case the first row of the table is deleted, as B1 is already removed from n1, +but pcb-rnd has no chance to decide if netlist adding B1 to n3 should affect +the table adding B1 to n2, so that rule is kept. +

+net_info is used to describe the original members of a net, in +the state they were before any change on the netlist occured. + +

Support in pcb-rnd: GUI

+A trivial idea is to extend the netlist window so that pins can be moved in +between nets or deleted or assigned to nets. Changes should be marked. This +is not the preferred way of editing the netlist, tho: not much more convenient +than making changes in gschem and doing forward annotation. +

+There should be a separate dialog box or a separate region of the netlist box +showing the netlist patch with edit capabilities. +

+Finally, the most important feature would be new actions resolving shorts. +Using the above example (n1=A1-B1 and n2=A2-B2 changed to n1=A1-B2 and n2=A2-B1), +I believe the user would: + +
action screenshot patch list after the actions +
  • look at initial rats
 (empty) +
  • first connect A1 to B1
 (empty) + +
    +
  • then realize it's very hard to connect A2 to B2 while the previous connection is there +
  • he would then revert the first connection +
  • and connect A1 to B2 +
  • which would cause shorts +
+ (empty) + +
    +
  • then he would use the "approve netlist change" hotkey/action on the network; + this would add netlist patch commands for the A1-B2 connection, + but would also keep the A1-B1 connection, which remains a rat; because + of the new connection there'd be a rat between A1 and A2 or B1 and B2 too + (all 4 pins connected together on the patched netlist at the moment!) +
+ +
+net_info n1 A1 B1
+net_info n2 A2 B2
+del_conn B1 n1
+add_conn B1 n2
+
+ +
    +
  • the user would then use an action (maybe the same one?) on the rat line + so that pcb-rnd would understand that rat is not needed anymore and + would add a patch to remove the A1-B1 connection +
  • the same thing would need to happen to the A2-B2 rat +
+ +
+net_info n1 A1 B1
+net_info n2 A2 B2
+del_conn B1 n1
+add_conn B1 n2
+del_conn B2 n2
+
+ + +
  • the user then would connect A2 to B1, which again is a short
 +
    +
  • the user would approve it as a new connection +
  • we have exactly 2 del_conn and 2 add_conn patches. +
+ +
+net_info n1 A1 B1
+net_info n2 A2 B2
+del_conn B1 n1
+add_conn B1 n2
+del_conn B2 n2
+add_conn B2 n1
+
+ +
+An experienced user may think a few steps in advance and +chose to first remove the A1-B1 and A2-B2 rats and then create the A1-B2 +and A2-B1 connections and then approve the two new connections. +

+An alternative is drag&drop ratline endpoint onto snap points; it may +be tricky to convert that to net/pin relations if a rat line is between two +line segments, tho. +

+These changes would live immediately, leaving the board free of shorts and +rats. There should be, however, some warning in the "congratulation" message +that tells the user a back annotation is still required. + +

Support in gschem

+Ideally there should be a very small change in gschem and an optional +plugin script could do the rest. The plugin script would be in contant +with foo. +

+There are multiple ways pins can be connected to a net in gschem. It's +probably not a good idea to have too much automatism in the gschem's side, +trying to actually removing connections and adding new ones using the patch +(or whatever info foo converted the patch into). +

+However, gschem should support four things natively: +

+

+Displaying unwanted connections happen at: +

+

+TODO: there are a lot to think over about special cases related to +multipage schematics, hierarchies, slots, split symbols. + +

What foo does exactly

+... is not clear yet. It depends on what sort of support gschem would provide. + +

Amendment 1: other parameters (1st sep)

+I originally forgot to mention my other intentions in the above document: +back annotate non-netlist properites. It probably happened because netlist +related stuff are the hardest to solve. +

+There are other parameters that sometimes change during routing. A common case +for my 1 or 2 layer boards is when I originally intend to use 0603 parts but +during routing I figure I need to pass a trace between the pads. I need to +change the part to 0805 or 1206 (for two traces). I'd like to be able to +do this in-place in pcb with an action that replaces the footprint +but keeps the origin in place. This obviously still requires some manual +fiddling afterwards, but would remove the long, tedious chain I have now: +

+

+The new process would be: +

+

+The same thing could work for values, which is the other attribute PCB also +sees. The same mechanism could work from other programs as well, e.g. tuning +the values of some parts in a simulator and then back annotating the changes +to the schematics. The patch table format foo handles would be in the +simplest plain text form. + + +

Amendment 2: examples from gschem's point of view (3rd Sep)

+

netlist change

+ + +

attribute change: footprint change

+ + Index: trunk/doc/devlog/20150901a_back_ann.html =================================================================== --- trunk/doc/devlog/20150901a_back_ann.html (nonexistent) +++ trunk/doc/devlog/20150901a_back_ann.html (revision 5594) @@ -0,0 +1,87 @@ + + +

pcb-rnd devlog

+ +

back annotation

+ + +

Conclusions of the first thread

+DJ has another model +where back annotation is only a subset of a bigger mechanism. +

+Many other users commented the thread, but no one else presented a +plan that formed a complete system. +

+While there were some useful feedback about some details, no one explicitly +said he'd be contributing the gschem part (... for any of the ideas floating +around). +

+The thread is swamped in a chaotic set of random ideas and opinions - the +same way as previous related threads usually did. + + +

Second thread

+In the second thread I will focus on actual contribution. For this, +I'm narrowing down what exactly needs to be contributed: + + + +

+First, I seek a contributor for exactly these 3 things. Alternatively if +there's someone who is really willing to contribute actual code and spend +time on this, I'm open to change parts of my plan if he has better ideas +as long as the new approach still solves the actual problems I have. + + +

Preparing for the third phase (3rd sep)

+Options are being eliminated slowly. I couldn't find out who are currently the +maintainers of gschem, so I couldn't ask their opinion about my back annotation +plan directly. Last stable release is about 2 years old, last unstable is more +than a year old. +

+The main options currently are: +

+There are some other options, but those are just variants of the above three. +Currently I think option 1 is unlikely to work, for I don't touch git, +and noone wants to touch scheme. Both 2 or 3 could work, but the total lack +of gschem maintainer feedback doesn't make option 2 look too good. + Index: trunk/doc/devlog/20151028_glib.html =================================================================== --- trunk/doc/devlog/20151028_glib.html (nonexistent) +++ trunk/doc/devlog/20151028_glib.html (revision 5594) @@ -0,0 +1,65 @@ + + +

pcb-rnd devlog

+ +

why glib is a bad idea

+ +Levente tried to compile pcb-rnd on bsd and used a different c compiler +than gcc. For this in the first step I fixed the build system so that it +doesn't have gcc --std=gnu99 but gcc --std=c99. +

+And then everything broke. A minilib I use for hashing, +genht, failed to +link against hid/common/action.c. I first thought it was a bug in genht: +genht was compiled without --std while the rest of the code compiled with +--std=gnu99 or --std=c99. Genht heavily depends on static inline +functions for performance, maybe that's why. +

+So I tried to reproduce the situation in a hello-world like program and +tried all combinaton of --std, -DNDEBUG, -rdynamic and all build flags +used in pcb-rnd for the genht lib and the test program, but all combination +worked. It looked like it broke only in pcb-rnd. +

+I gave up on the minimal test case and went back to pcb-rnd. I realized if +the build is the same, the only way it may break is that some header +included before genht's headers change some global state. I started to +shuffle the #includes. Long story short, it turned out if <glib.h> is +included before genht's headers, it breaks. +

+Some more tracing showed it was because glib over-#defines the keyword +inline in a public header that gets included from glib.h. It's all wrapped +in a complicated tree of #ifdefs, so it behaves differently depending on +the --std setting. +

+The morale of the story is... Well, I have multiple conclusions. +

+ +

+In a nuthsell this is why I don't believe in glib-like solve-all megalibs. I +don't say size alone determines this, but size is a good indication of +potential problems. +

+If I need hash and lists and the offer is longer than 5k sloc, I know it +will bring a lot of unneeded bloat that likely to break things. + + + \ No newline at end of file Index: trunk/doc/devlog/20160101_cschem.html =================================================================== --- trunk/doc/devlog/20160101_cschem.html (nonexistent) +++ trunk/doc/devlog/20160101_cschem.html (revision 5594) @@ -0,0 +1,68 @@ + + +

pcb-rnd devlog

+ +

cschem

+ +Cschem is a project I plan to start within the next few years. It's goals +and some design concepts are similar to gschem's and geda's, while it +also breaks some traditions to fix shortcomings in the design of geda. It's +named after gschem, not after geda, to emphasize that the editor needs to +be connected more to the rest of the system (see details later). +

+Some concepts cschem will try to follow (marking with * where there's major +difference to geda): +

+ + +

+There are a lot of open questions: +

+ Index: trunk/doc/devlog/20160126.html =================================================================== --- trunk/doc/devlog/20160126.html (nonexistent) +++ trunk/doc/devlog/20160126.html (revision 5594) @@ -0,0 +1,59 @@ + + +

pcb-rnd devlog

+ +

Burried/blind via poll

+ +

Results

+ +I received 10 full answers to the poll - thanks everyone who +answered. This is a small sample, but this is the best I could get +(I can't reach more pcb users). +

+Raw results are available in html, tsv and +csv format. + +

My interpretation

+ +(User obviously means "those users who answered the poll") + + + +

My conclusions

+Because of 1. and 2., pcb-rnd doesn't seem to need blind/burried vias. The +purpose of question 7 was to find out whether users value this feature high +enough to actually consider investing time/effort in return, compared to +question 6. This pair of questions was designed to avoid noise that comes +from the fact that we, on the list tend to express our opinions in vast +crowds while only a few invest more time than talking and do actual work. +According to the result of line 7, my conclusion is that it's absolutely +not blind/burried vias that potential pcb-rnd users need. Thus +my decision is that I won't spend time on this feature in the near future. +

+The situation for pcb might be different, tho. I worded the first 4 questions +to find out how strong the need is among the users of mainline pcb and whether +they are devoted to pcb or choose the tool according to the design requirements. +There seems to be a correlation between having to use blind/burried vias +and using other layout tools. Or in other words: those who are happy with pcb +usually don't need or want blind/burried vias anyway and those who do have +already switched to another tool. +

+This suggests mainline pcb could benefit from burried/blind vias. However, +the demand is much lower than "every new design needs this" or "no new +user would consider pcb because of this missing feature". +

+Linux: it seems pcb power users mostly use Linux. I am not sure if it's +because PCB works well on Linux and is a bit harder to compile on +anything else - or the other way around (Linux users are more attracted +to PCB). + + + + + + Index: trunk/doc/devlog/20160313_unglib.html =================================================================== --- trunk/doc/devlog/20160313_unglib.html (nonexistent) +++ trunk/doc/devlog/20160313_unglib.html (revision 5594) @@ -0,0 +1,49 @@ + + +

pcb-rnd devlog

+ +

unglib: glib removal

+ +

glib problems

+ +As mentioned in a previous post, glib is +sometimes dangerous. Even if it was not, it's still huge and contradicts +the UNIX philosophy: Do One Thing and Do It Well. Glib tries to do a lot +of things. I do not doubt it is trying to do each of these things well, but as +a combination it's pretty much impossible to Keep It Simple, Stupid. +While glib is modular in design, from the viewpoint of an application it is +not modular: it's highly unlikely that the application can replace a part +of glib while keeping the rest. +

+The source of these problems is that glib is a "megalib" that tries to solve +a host of problems as a package. + +

The solution

+ +The solution is to replace the megalib with +a set of independent minilibs. Each minilib: + +

+The minilibs are imported as svn externals in trunk/src_3rd. They are small +enough so that they can be distributed together with pcb sources. + +

Current state

+ +The "unglib" patch is mostly done. All references of glib are removed +from the core and the lesstif hid. There are a three components that +still depend on glib, but they each can be disabled: + +

+This means pcb-rnd can be compiled with lesstif (or a compatible motif) +on a UNIX box without depending on glib. Together with the earlier effort +that removed autotools, it means a UNIX box without any "GNU infection" +should be able to compile and run pcb-rnd. Index: trunk/doc/devlog/20160314_valgrind_flex.html =================================================================== --- trunk/doc/devlog/20160314_valgrind_flex.html (nonexistent) +++ trunk/doc/devlog/20160314_valgrind_flex.html (revision 5594) @@ -0,0 +1,79 @@ + + +

pcb-rnd devlog

+ +

"valgrinding" flex/bison parsers

+ +In a flex/bison parser it's quiet common that strings are allocated +in flex, passed on to bison and then either free'd there or saved in +the output data. Since both free and save happens a lot, it's not an +easy mechanical review of the .y file to find the reason for leaks. Especially +if the code has to store some strings in temporary storage until a later +stage of the parsing. +

+A typical valgrind log for such a leak looks like this: +

+==20520== 20 bytes in 1 blocks are still reachable in loss record 3 of 6
+==20520==    at 0x402B0D5: calloc (vg_replace_malloc.c:623)
+==20520==    by 0x80E6EF0: yylex (parse_l.l:177)
+==20520==    by 0x80E0D6C: yyparse (parse_y.tab.c:1696)
+==20520==    by 0x80E85ED: Parse (parse_l.l:292)
+==20520==    by 0x80E876B: ParsePCB (parse_l.l:347)
+==20520==    by 0x8078591: real_load_pcb (file.c:390)
+==20520==    by 0x80787E9: LoadPCB (file.c:459)
+==20520==    by 0x8097719: main (main.c:1781)
+
+ +The code at parse_l.l:177 is just a calloc() and some string +operation: this is where the string is created. The STRING token is +referenced about 58 times in the grammar. After reading through the +whole file 4..5 times, I still didn't see any obvious place for the leak. +

+The leak was also a rare one: happened for one string per file. This suggested +it was in the header - unless there's an one-instance object somewhere in the +.pcb or it's a cache where the same pointer is free()'d and overwritten for +multiple occurrences and simply no one free()'s the last. +

+Assuming it's a header, a cheap ways to find which header field leaked: +

+

+At this point I figured that I'd depend on the reported size of the leak +with my tests. I didn't want to do multiple runs and didn't want to risk +the whole parser to run differently so I didn't want to modify the input. Instead +I figured there's a simple, yet generic way to track these sort of leaks. +

+I estimated no string in the file is longer than 1000 characters. Right above +the calloc() in the lexer I introduced a new static integer variable starting +at 1000, increased before each allocation. This counter is sort of an ID of +each allocation. Then I modified the calloc() to ignore the originally calculated +string length and use this ID for allocation size. I also printed the ID-string +pairs. The original code looked like this (simplified): +

+	/* ... predict string size ... */
+	yylval.str = calloc(predicted_size, 1);
+	/* ... build the string here ... */
+	return STRING;
+
+ +The resulting code looked like this (simplified): +
+	/* ... predict string size ... */
+	static int alloc_id = 1000;
+	alloc_id++;
+	yylval.str = calloc(alloc_id, 1);
+	/* ... build the string here ... */
+	fprintf(stderr, "STRING: %d '%s'\n", alloc_id, yylval.str);
+	return STRING;
+
+I saved the list printed on stderr and checked valgrind's log to find +the two strings in question were ID 1002 and ID 1007, both looked +something like this: +
+1,3,4,c:2,5,6,s:7:8
+
+The only thing that looks like this is the layer group description ("Groups()"). +From this point it was trivial to find the bug in the grammar. + Index: trunk/doc/devlog/20160409/header =================================================================== --- trunk/doc/devlog/20160409/header (nonexistent) +++ trunk/doc/devlog/20160409/header (revision 5594) @@ -0,0 +1,7 @@ +1. Do you use the lesstif HID? +2. If there were different menu resources files distributed with PCB, would you try them? +3. Do you customize your menu resource file? +4. If you do not costumize your menu resource file, it's because +5. Do you miss multi-key sequences from the GTK hid? +6. If the GTK hid supported multi-key sequences, would that change any of your previous answers? +7. Vendor (drill) mapping also uses a resource file. Index: trunk/doc/devlog/20160409/header.csv =================================================================== --- trunk/doc/devlog/20160409/header.csv (nonexistent) +++ trunk/doc/devlog/20160409/header.csv (revision 5594) @@ -0,0 +1 @@ +1. Do you use the lesstif HID?,2. If there were different menu resources files distributed with PCB, would you try them?,3. Do you customize your menu resource file?,4. If you do not costumize your menu resource file, it's because,5. Do you miss multi-key sequences from the GTK hid?,6. If the GTK hid supported multi-key sequences, would that change any of your previous answers?,7. Vendor (drill) mapping also uses a resource file., \ No newline at end of file Index: trunk/doc/devlog/20160409/legend.txt =================================================================== --- trunk/doc/devlog/20160409/legend.txt (nonexistent) +++ trunk/doc/devlog/20160409/legend.txt (revision 5594) @@ -0,0 +1,60 @@ +1. Do you use the lesstif HID? (select one) +a. yes, exclusively +b. yes, often +c. sometimes, rarely +d. never + + +2. If there were different menu resources files distributed with PCB, +would you try them? (select one) +a. yes, I'd give each variant a try before deciding which one to use +b. no, I'm fine with the default +c. I don't know what a menu resource file is + + +3. Do you customize your menu resource file? (select one) +a. yes, always (e.g. I have an own variant I use with all installation of +PCB) +b. yes, sometimes, rarely (e.g. I once had to do something repeatedly and +added a key binding for that) +c. never, I know where I'd perform the changes if I ever needed +them but defalts are good enough for now +d. never, I don't know what a menu resource file is + + +4. If you do not costumize your menu resource file, it's because (select +zero or more): +a. I don't need to +b. the file is too long +c. too many keys are taken, it's hard to find a free one +d. I don't like the format of the file +e. I don't like the idea of editing text config files, I want a GUI for +this +f. I don't want to diverge from the default settings (e.g. because of +potetial hassle at a later upgrade) + + +5. Do you miss multi-key sequences from the GTK hid? (select one) +a. yes, I'd prefer to use them over modifiers (ctrl, alt, shift) +b. yes, I'd use them together with the modifiers +c. maybe I'd use some +d. no, I prefer modifiers +e. I hate the idea so much that I'd even disable it compile time if that +was possible +f. N/A, don't know + + +6. If the GTK hid supported multi-key sequences, would that change any of +your previous answers? (fill in zero or more with a letter) +a. my new choice for 2. would be: +b. my new choice for 3. would be: + +7. slightly off-topic: vendor (drill) mapping also uses a resource file. +Do you use this feature? (select one) +a. yes, often, many of my boards rely on vendor mapping and I maintain +my own resource files per vendor +b. yes, sometimes, rarely (e.g. I needed it once...) +c. no, I know how to use it but never needed it +d. no, I know the feature exists and I know where to look it up but I +don't really know what exactly it can do or why I should bother +e. no, I never heard about this feature Index: trunk/doc/devlog/20160409/pie_col_1.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_1.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_1.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_1.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_1.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/pie_col_2.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_2.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_2.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_2.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_2.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/pie_col_3.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_3.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_3.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_3.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_3.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/pie_col_4.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_4.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_4.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_4.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_4.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/pie_col_5.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_5.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_5.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_5.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_5.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/pie_col_7.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: trunk/doc/devlog/20160409/pie_col_7.png =================================================================== --- trunk/doc/devlog/20160409/pie_col_7.png (nonexistent) +++ trunk/doc/devlog/20160409/pie_col_7.png (revision 5594) Property changes on: trunk/doc/devlog/20160409/pie_col_7.png ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: trunk/doc/devlog/20160409/poll.csv =================================================================== --- trunk/doc/devlog/20160409/poll.csv (nonexistent) +++ trunk/doc/devlog/20160409/poll.csv (revision 5594) @@ -0,0 +1,9 @@ +a,a,a,-,-,-,c +d,a,c,f,a,-,d +b,a,b,-,c,-,c +d,c,d,a+f,c,-,e +d,b,c,a+f,b,-,b +d,a,a,a,d,-,c +-,a,c,-,a,-,- +c,a,b,f,a,-,c +c,a,c,-,a,-,- Index: trunk/doc/devlog/20160409/poll.html =================================================================== --- trunk/doc/devlog/20160409/poll.html (nonexistent) +++ trunk/doc/devlog/20160409/poll.html (revision 5594) @@ -0,0 +1,98 @@ + + + +
1. Do you use the lesstif HID? +2. If there were different menu resources files distributed with PCB, would you try them? +3. Do you customize your menu resource file? +4. If you do not costumize your menu resource file, it's because +5. Do you miss multi-key sequences from the GTK hid? +6. If the GTK hid supported multi-key sequences, would that change any of your previous answers? +7. Vendor (drill) mapping also uses a resource file. +
aaa---c +
dacfa-d +
bab-c-c +
dcda+fc-e +
dbca+fb-b +
daaad-c +
-ac-a-- +
cabfa-c +
cac-a-- +
+ + + + +  + +
+

+

Legend

+
+1. Do you use the lesstif HID? (select one)
+a. yes, exclusively
+b. yes, often
+c. sometimes, rarely
+d. never
+
+
+2. If there were different menu resources files distributed with PCB, 
+would you try them? (select one)
+a. yes, I'd give each variant a try before deciding which one to use
+b. no, I'm fine with the default
+c. I don't know what a menu resource file is
+
+
+3. Do you customize your menu resource file? (select one)
+a. yes, always (e.g. I have an own variant I use with all installation of 
+PCB)
+b. yes, sometimes, rarely (e.g. I once had to do something repeatedly and 
+added a key binding for that)
+c. never, I know where I'd perform the changes if I ever needed 
+them but defalts are good enough for now
+d. never, I don't know what a menu resource file is
+
+
+4. If you do not costumize your menu resource file, it's because (select 
+zero or more):
+a. I don't need to
+b. the file is too long
+c. too many keys are taken, it's hard to find a free one
+d. I don't like the format of the file
+e. I don't like the idea of editing text config files, I want a GUI for 
+this
+f. I don't want to diverge from the default settings (e.g. because of 
+potetial hassle at a later upgrade)
+
+
+5. Do you miss multi-key sequences from the GTK hid? (select one)
+a. yes, I'd prefer to use them over modifiers (ctrl, alt, shift)
+b. yes, I'd use them together with the modifiers
+c. maybe I'd use some
+d. no, I prefer modifiers
+e. I hate the idea so much that I'd even disable it compile time if that 
+was possible
+f. N/A, don't know
+
+
+6. If the GTK hid supported multi-key sequences, would that change any of 
+your previous answers? (fill in zero or more with a letter)
+a. my new choice for 2. would be:
+b. my new choice for 3. would be:
+
+7. slightly off-topic: vendor (drill) mapping also uses a resource file. 
+Do you use this feature? (select one)
+a. yes, often, many of my boards rely on vendor mapping and I maintain 
+my own resource files per vendor
+b. yes, sometimes, rarely (e.g. I needed it once...)
+c. no, I know how to use it but never needed it
+d. no, I know the feature exists and I know where to look it up but I 
+don't really know what exactly it can do or why I should bother
+e. no, I never heard about this feature
+
+

Downloads

+