- We have a new main page reflecting the transition how we regard pcb-rnd:
- it is not much of just a fork of geda/pcb by now, but a separate PCB
- editor with its own team and own course. File save/load compatibility is
- maintained.
-
-
-
- 2016-08-24
-
- Release 1.1.1
-
- Available at the download page .
-
- The next development cycle will focus on editable/searchable attributes
- and a new native file format.
-
-
I'm normally online as Igor2 between 5:00 CET and 19:00 CET; on Sunday there's an AFK-window between 11:00 CET and 16:00 CET. If I don't answer in a few minutes I'm probably away doing something, please be patient; say hi before you type your long question so you see if I'm available.
-
-
-Below is an iframe of
-kiwiirc irc client configured with the above settings. If it doesn't
-work, please visit their page and
-try to manually configure it, it's just 4 fields.
-
-Using the web client: you may change your nickname; there's no password
-or registration or channel key or ssl of any form. Your real IP won't be
-shown on the IRC network (check kiwiirc's page about thier privacy
-policy).
-
-Connecting with the web client may take some time, give it a minute.
-
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.
-
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.
-
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 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.
-
-
-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 1: the output list is reset to empty
-
step 2: all sources that describe the list are sorted by priority
-
step 3: sources are applied in order
-
-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.
-
-
-
-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.
-
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-rnd/conf/sources.html
===================================================================
--- trunk/doc-rnd/conf/sources.html (revision 5606)
+++ trunk/doc-rnd/conf/sources.html (nonexistent)
@@ -1,72 +0,0 @@
-
-
-
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-rnd/conf/plugin_chk.html
===================================================================
--- trunk/doc-rnd/conf/plugin_chk.html (revision 5606)
+++ trunk/doc-rnd/conf/plugin_chk.html (nonexistent)
@@ -1,7 +0,0 @@
-
-
-
-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:
-
-
HID attributes: another way to describe name-type-metadata lists; this
- was used to pass on some rc-like parameters to the GUI HIDs. It's also the
- main API to describe export parameters for the export HIDs. However,
- HID attributes is not well suited for saving plugin (or HID) user
- preferences, it is more about a per action configuration.
-
-
The gtk HID also saved its own settings to a separate file called
- ~/.pcb/preferences.
-
-
Some gtk HID settings didn't quiet fit in the preferences - the color
- scheme can be saved in another file, usually under ~/.pcb/colors
-
-
A random plugin could either use the HID attributes to get a limited
- service or like the gtk HID did, had to implement its own save-restore of
- persistent settings.
-
-
-
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-rnd/conf/index_user.html
===================================================================
--- trunk/doc-rnd/conf/index_user.html (revision 5606)
+++ trunk/doc-rnd/conf/index_user.html (nonexistent)
@@ -1,92 +0,0 @@
-
-
-
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:
-
-
first merge all the role treesinto a flat list; this determines the value of each setting;
-
then dispatch the values to the right component of the code.
-
-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-rnd/conf/syntax.html
===================================================================
--- trunk/doc-rnd/conf/syntax.html (revision 5606)
+++ trunk/doc-rnd/conf/syntax.html (nonexistent)
@@ -1,45 +0,0 @@
-
-
-
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:
-
-
srtuctural nodes usually start with a ha: or li: prefix; which one needs to be used is pretty much tied to the node name; thus casual users don't need to care about what they are for, just remember them as part of the name
-
non-structural nodes are usually given in the form of name = value; use braces around the value if it contains any non-alphanumeric, non-whitespace character
-
list and array members should better be braced
-
list and array separator should be semicolon (not comma)
-
-
-
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.
-
-The old config system had several limitations that would have been
-hard to fix keeping the original design:
-
-
config settings were specified in a flat list - no grouping
-
the core had a rather static system - HIDs or plugins couldn't extend it, thus they had to invent their own config files
-
... this led to a variety of configuration formats; using one format not always because it was better suited for the task, but for historical reasons
-
... this also led to a collection of config files - again not always split by boundaries of settings, but often by arbitrary boundaries of code
-
the old system didn't support lists or arrays well
-
it didn't have a coherent concept of how settings from different sources would override eachother
-
... this resulted in the rigid structure that most of the settings could come from only one place (e.g. if it's an user setting, the design won't be able to override it)
-
... a config file can overwrite a list or prepend/append to it (e.g. design-level config prepending an extra library path keeping system set paths as well)
-
there are different sources of configuration, e.g. system-wise, user-wise, project-wise, etc.
-
the user has the power to change default config priorty per setting; e.g. normally design config overrides user config, but it's possible to mark a setting from user config so strong that it overrides even the setting read from the .pcb file
-
the way settings are stored is flexible and extensible so that a plugin can define their subtree of settings
-
... since the API even makes it easier to access such settings (vs. parsing your own config file), plugins will tend to use the unified config format/system instead of inventing teir own
-
... the GUI (gtk's preferences dialog) thus can automatically handle the new settings
-
... plugins don't have to implement actions to set/toggle/query their settings for the menu system, there are generic config set/toggle/query actions the menu config can use
-
-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-rnd/conf/merging.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/conf/merging.png
===================================================================
--- trunk/doc-rnd/conf/merging.png (revision 5606)
+++ trunk/doc-rnd/conf/merging.png (nonexistent)
Property changes on: trunk/doc-rnd/conf/merging.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/conf/scalars.html
===================================================================
--- trunk/doc-rnd/conf/scalars.html (revision 5606)
+++ trunk/doc-rnd/conf/scalars.html (nonexistent)
@@ -1,56 +0,0 @@
-
-
-
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-rnd/conf/prio.html
===================================================================
--- trunk/doc-rnd/conf/prio.html (revision 5606)
+++ trunk/doc-rnd/conf/prio.html (nonexistent)
@@ -1,22 +0,0 @@
-
-
-
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-rnd/logo32.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/logo32.png
===================================================================
--- trunk/doc-rnd/logo32.png (revision 5606)
+++ trunk/doc-rnd/logo32.png (nonexistent)
Property changes on: trunk/doc-rnd/logo32.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/logo16.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/logo16.png
===================================================================
--- trunk/doc-rnd/logo16.png (revision 5606)
+++ trunk/doc-rnd/logo16.png (nonexistent)
Property changes on: trunk/doc-rnd/logo16.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/help.html
===================================================================
--- trunk/doc-rnd/help.html (revision 5606)
+++ trunk/doc-rnd/help.html (nonexistent)
@@ -1,62 +0,0 @@
-
-
-The project is looking for volunteers for the features listed below. If
-you want to contribute, you will need to have an svn client and an email
-client. Furthermore an IRC client is strongly recommended.
-
-You will become part of the team and get svn commit right immediately
-when you start working.
-
-Don't have much free time? Don't worry: the tasks below are split up in
-very small (1..2 hours) chunks. Coordination is granted, the administrative
-overhead is almost zero - you can focus on the task, and finish it whenever
-you have a free hour.
-
-Worrying about your contribution to go in /dev/null? Don't: pcb-rnd
-has very short loops; you start contributing and get immediate feedback. Your
-work is part of the official thing immediately and revised and accepted (or
-rarely refused) within hours or at most days.
-There are no bitrotting branches.
-
-You are not confident enough with your skills? pcb-rnd is an optimal
-project for learning. If you start contributing, you get support. There
-are small and simple entry level tasks. Most of the tasks don't require
-any programming skills.
-
-Sign up: mail to pcb-rnd (at) igor2.repo.hu .
-If you want to work on a feature not listed below, feel free to drop me
-a mail.
-
-
-
ID
skill required
description
-
tutorial
geda user
tutorial projects
-
windows
geda user
generic testing on windows
-
mtest
geda user
systematic manual testing
-
doc
geda user, html
write sections of user documentation
-
logo
designer
the official pcb-rnd logo
-
banner
designer
pcb-rnd banner for the homepage
-
icons
designer
icons, other graphical elements for the GTK HID
-
css
designer
CSS for the homepage (only design/style, no content).
-
-I use PCB a lot on various computers. I used to try to join the mainstream
-development with small contribution (minor patches) and was active on
-IRC and the mailing lists for a while. However, it didn't work out well,
-and:
-
-
PCB already knew 95% of everything I'd ever need years ago
-
the remaining 5% was not on the TODO list of developers and generally no one shown much interest in getting patches for those
-
meanwhile a lot of new features have been added, from which most I find totally useless:
-
-
dbus
-
gl - transparency makes even simple 2 sided boards unusable; slower than the classic version sw render on all my computers
-
preparation for a C++ transition
-
3d support in core (I believe communication to 3d cad programs should be via exporter plugins)
-
-
the official Debian package enables (requires, depends on) both dbus and gl
-
DVCS - it almost always results in chaos, and has no benefit for such a small group of developers; there are posts from time to time on the mailing list about how to handle the chaos; my choice is to stick with a simple, centralized version control system
-
DVCS always results in increased administration, which I hate to spend my time on - I'd rather invest the time in bugfixing, documentation or implementing new features
-
it's nearly impossible to get small patches applied^1:
-
-
often no one has the time to revise and commit them
-
communication requires web2.0 (lp)
-
there are too many cycles of "please fix this and change that first"
-
with the chaos VCS, it's too likely that new feature patches would require ongoing maintenance while sitting in a "feature branch", to avoid that a large scale merge (or rebase, whatever) breaks it when it finally hits the official branch
-
there are too much pondering and too less prototyping; there are features that are being considered for years (for example back annotation, internal connections) with multiple concurrent ideas, but no code. Instead, I'd like to implement some code from the early phase of the idea, test it, and deprecate it if it didn't work out well.
-
I wouldn't even dream about getting larger patches in the official release
-
-
no stable release for years; maintaining a set of patches (like pcb-gpmi) and porting them to new releases is too much hassle
-
-I was pondering a fork for years. The trigger was that one day I've upgraded
-Debian on my lab computer and the new version of PCB came with gl enabled; this
-made PCB absolutely unusable (had to wait like 10 seconds for a scroll) while
-all the transparent polys over traces made the whole screen a mess. I should
-have recompiled everything and built a new Debian package with gl disabled or
-install from source (but I have too many computers for that). My decision
-was to set up my own .deb but then build it from a fork (it's not much of
-an extra effort), so I can add some of the features I miss in daily use.
-My plans with this fork:
-
-
I stick with my fork and will use it on all my computers for all my designs
-
Because of that, there's no emphasis on keeping the file formats compatible - breaking compatibility is not a goal either; as long as mainline doesn't change the format, pcb-rnd is about 98% compatible (the 2% is where pcb-rnd features are not supported by mainline)
-
I won't actively seek ways to get my changes into the mainstream; I will keep on using my svn repo in a manner that (as a side effect) makes such merges easier, tho. If PCB developers decide to pick them up from svn and merge them in the official repo, it's fine (but I personally will keep using my fork anyway).
-
Most probably I won't merge anything back from the mainstream to my fork - the past few years showed that it's unlikely there would be new features I'd need
-
1206 jumpers without having to add them on the schematics/netlist (done: [intconn] and [nonetlist] are the PCB-side features for this)
-
merge pcb-gpmi; GPMI would be an optional addon, it'd probably stay a plugin, but there should not be a separate repo ( done )
-
-
-
-Footnotes:
-
-
^1: this may have changed lately and pcb developers are more open to newcomers; there seems to be a shortage of developers tho, which still makes it slow to get bigger patches through
-
-
-
Phase 2: major cleanups (2015..2016)
-In the first phase I was mostly implementing a set of small features and fixes.
-As I got more familiar with the code base, I decided to bite the bullet and
-do some refactoring:
-
-
replaced the footprint mapping/loading code; instead of a hardwired m4 dependency, parametric (generated-on-the-fly) footprints can be written in any language
-
replaced the default footprint library shipped with the software; the new library ships a small, well organized collection of essentials, omitting special/rarely used footprints
-
threw out the resource parser and file format (manu.res and friends) in favor of lihata; this removed a lot of code duplication and a strangely designed resource tree data structure I really hated; as a side effect the gtk hid has multi-stroke hotkeys
-
replaced glib with a set of mini libs in core and most of the plugins; at the end only the gtk hid should depend on glib; this made the code easier to maintain and debug; a lot of checks are now compile-time (through the C type system) instead of runtime (glib lists)
-
replaced the settings/rc/preferences system with a central, lihata based configuration system - long term hid attributes will be converted too
-
-
-Plans for the future includes:
-
-
turning most of the core code into a library for external tools to reuse
-
extending the core to provide an infrastructure for composite objects handled by plugins
-
support for saving and loading pcb and footprint files in the lihata format
-
plans for a set of smallish features that can be implemented in a weekend or two each.
-
-
-
Phase 3: community requested features (from 2016 onward)
-Overlapping phase 2 there is an ongoing
- feature poll . If there
-are enough active users/testers for a feature, it gets implemented in
-phase 3.
-
-There is a small, active, constructive community forming around pcb-rnd. Future
-directions will be mainly set by their need.
-
-
-
Index: trunk/doc-rnd/Autostyle.html
===================================================================
--- trunk/doc-rnd/Autostyle.html (revision 5606)
+++ trunk/doc-rnd/Autostyle.html (nonexistent)
@@ -1,14 +0,0 @@
-
-
-
-
-
-
-
Index: trunk/doc-rnd/UNIX.txt
===================================================================
--- trunk/doc-rnd/UNIX.txt (revision 5606)
+++ trunk/doc-rnd/UNIX.txt (nonexistent)
@@ -1,31 +0,0 @@
-State on UNIX systems
-~~~~~~~~~~~~~~~~~~~~~
-
-Source releases starting from 1.1.2 should compile and run out-of-the-box
-on old UNIX systems, such as IRIX. Does NOT require any GNU installed.
-
-Requirements:
- - x11 and motif (for the GUI)
- - an awk implementation that supports gsub(), e.g. nawk
-
-1. If your C compiler does not support #warning, run a script to patch
- the source:
-
- # cwd is the root of the distribution
- util/workarounds/unwarn_all.sh
-
- This will take a while and will modify a lot of .c files.
-
-2. ./configure
-
-3. make
-
-Considerations listed in ../INSTALL apply.
-
-The above procedure has been tested on IRIX 5.3 on IP22.
-
-Expected compilation times [minute:second]:
-
-./configure compile, -O0 compile -O3 system
--------------------------------------------------------------------------------
-1:55 7:40 14:27 IRIX 5.3, IP22 @ 100 MHz
Index: trunk/doc-rnd/packaging.txt
===================================================================
--- trunk/doc-rnd/packaging.txt (revision 5606)
+++ trunk/doc-rnd/packaging.txt (nonexistent)
@@ -1,90 +0,0 @@
-Packaging pcb-rnd for a distribution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-1. program, libs, desktop integration
-
-Pcb-rnd is an interactive printed circuit board editor program. A typical
-user is an electric engineer. This sort of programs are often called EDA,
-Electronics Design Automation.
-
-Pcb-rnd has different frontends: graphical and stdio/text based batch
-processing. There are different graphical frontends - pcb-rnd does not
-depend on gtk or motif, the specific frontend modules may depend on them.
-
-Pcb-rnd is scriptable if libgpmi is available. Since libgpmi is not
-a mainstream library for the scripting feature it should also be packaged.
-
-Pcb-rnd is intended for UNIX-fans. It is heavily keyboard-oriented and it
-doesn't assume its users don't want to understand or learn how it works.
-Many typical user workflows include Makefiles and it's a common thing to
-start pcb-rnd from a shell. Thus desktop integration is not in focus
-at the moment. If you fixed things for this while packaging, please let
-us know, we may merge your patches (see below).
-
-2. options, plugins, dependencies
-
-Pcb-rnd is a modular software with a lot of options. Majority of these options
-are selected by the state of a module. A module has three states:
- - disable: (not compiled at all)
- - buildin: enabled and static linked
- - plugin: enabled and dynamic loaded (from a .so)
-
-The configure script takes --disable-*, --building-* and --plugin-*
-arguments with * substituted with the name of the module. The configure
-script also determines the dependencies according to the selection. Special
-arguments --all=plugin and --all=buildin are provided in configure to select
-all working modules to be plugins or buildins.
-
-For binary distributions it's strongly recommended to have most of the
-modules compiled as plugins and have them in separate packages. This
-would let the user to install a core pcb-rnd package and then the GTK
-or the lesstif plugin (or both) from separate packages. This also reduces
-package dependencies.
-
-This is less relevant for source distributions, if the user has full control
-over the configuration.
-
-If non-critical dependencies are not met, modules are automatically disabled
-by ./configure.
-
-3. typical ./configure options - scconfig vs. auto*
-
-./configurfe --prefix works as expected. DESTDIR is called install_root.
-
-Typical commands for configuring pcb-rnd for packaging would be:
-
- ./configure --all=plugin --prefix=/usr
- make all
- install_root=/tmp/pkg_tmp make install
-
-We are happy with scconfig. Please don't write about how much better
-autoconf or cmake would be, we won't switch.
-
-4. release cycles, tarballs, svn trunk - what to package
-
-Development happens in svn trunk/, there are usually no branches. While
-we try to keep trunk/ compilable any time, it's not guaranteed that it
-would work out-of-the-box between releases. It is not recommended to
-package trunk/ - please package stable releases instead.
-
-We follow the "release early, release often" rule. Source release tarballs
-are always considered stable. Beside the project web page, releases are
-also accessible as svn tags: svn://repo.hu/pcb-rnd/tags .
-
-Sometimes we have minor releases with 1..2 month period, sometimes a
-longer period passes between releases.
-
-There's no automated release notification at the moment; if you want to
-get notified about new releases, please contact me (email
-pcb-rnd (at) igor2.repo.hu)
-
-5. bug reporting and fixes for packaging
-
-There's no special method for reporting packaging related bugs and
-feature requests, please follow the normal bug report instructions or just
-drop me a mail. Please mention that the issue is related to packaging, this
-usually gives it a higher priority.
-
-We are willing to make minor changes to make packaging easier - if you bump
-into something you'd need to work around while packaging, please let us know,
-we may just fix it "upstream".
-
Index: trunk/doc-rnd/mods/gen.sh
===================================================================
--- trunk/doc-rnd/mods/gen.sh (revision 5606)
+++ trunk/doc-rnd/mods/gen.sh (nonexistent)
@@ -1,128 +0,0 @@
-#!/bin/sh
-
-path=../../src_plugins
-
-sloc()
-{
- (cd "$1" && sloccount .) | awk '/^Total Phys/ { size=$9; sub(",", "", size); print size }'
-}
-
-gen_pie()
-{
- local bn=$1 code_size=$2 color=$3
- echo ""
- echo "@slice"
- echo "$code_size"
- echo "@label"
- echo "$bn ($code_size)"
- if test ! -z "$color"
- then
- echo "@color"
- echo "$color"
- fi
-}
-
-echo "#autogenerated by gen.sh" > mods.pie
-echo "#autogenerated by gen.sh" > after.pie
-
-echo HIDs >&2
-code_size=`sloc ../../src/hid`
-gen_pie "HIDs" $code_size "orangered" >> after.pie
-
-echo Core >&2
-tmp=/tmp/pcb-mods-stat
-mkdir $tmp
-cp -r ../../src/*.c ../../src/*.h ../../src/Makefile* $tmp
-code_size=`sloc $tmp`
-gen_pie "core" $code_size "#00ff88" >> after.pie
-
-#echo 3rd >&2
-#code_size=`sloc ../../src_3rd`
-#gen_pie "3rd" $code_size >> after.pie
-
-
-(
-cat pre.html
-for n in $path/*
-do
- if test -d "$n"
- then
- echo $n >&2
- bn=`basename $n`
- code_size=`sloc $n`
- total=$(($total + $code_size))
- gen_pie $bn $code_size >> mods.pie
-# case $bn in
-# gpmi) echo "@pull" >> mods.pie; echo "0.1" >> mods.pie;;
-# esac
-
- echo "
" desc
- }
- ' < $n/README
- fi
-done
-cat post.html
-gen_pie "plugins" "$total" "#0088ff" >> after.pie
-) > index.html
-
-for n in mods after
-do
- animpie < $n.pie | animator -H -d $n
- pngtopnm ${n}0000.png | pnmcrop | pnmtopng > $n.png
- rm ${n}0000.png
-done
-
Property changes on: trunk/doc-rnd/mods/gen.sh
___________________________________________________________________
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property
Index: trunk/doc-rnd/mods/after.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods/after.png
===================================================================
--- trunk/doc-rnd/mods/after.png (revision 5606)
+++ trunk/doc-rnd/mods/after.png (nonexistent)
Property changes on: trunk/doc-rnd/mods/after.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods/before.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods/before.png
===================================================================
--- trunk/doc-rnd/mods/before.png (revision 5606)
+++ trunk/doc-rnd/mods/before.png (nonexistent)
Property changes on: trunk/doc-rnd/mods/before.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods/mods.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods/mods.png
===================================================================
--- trunk/doc-rnd/mods/mods.png (revision 5606)
+++ trunk/doc-rnd/mods/mods.png (nonexistent)
Property changes on: trunk/doc-rnd/mods/mods.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods/post.html
===================================================================
--- trunk/doc-rnd/mods/post.html (revision 5606)
+++ trunk/doc-rnd/mods/post.html (nonexistent)
@@ -1,3 +0,0 @@
-
-
-
Index: trunk/doc-rnd/mods/pre.html
===================================================================
--- trunk/doc-rnd/mods/pre.html (revision 5606)
+++ trunk/doc-rnd/mods/pre.html (nonexistent)
@@ -1,60 +0,0 @@
-
-
-
pcb-rnd modularization
-
Why bother...
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-As of version 1.0.8 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.0.8
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-As of version 1.0.8 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.0.8
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-
module
size [sloc]
status
configure default
description
-
-
-
autoplace
608
-
works
-
buildin
-
Automatically place elements.
-
autoroute
4177
-
works
-
buildin
-
Automatically route selected or all rats. This is the original autorouter.
-
dbus
438
-
disabled
- (TODO: needs scconfig support)
-
disabled
-
Remote control PCB using DBUS.
-
djopt
2315
-
works
-
buildin
-
Various board optimization algorithms.
-
export_gcode
2450
-
works
-
buildin
-
Export to gcode
-
export_lpr
96
-
works
-
buildin
-
Export to lpr (using export_ps to generate postscript)
-
export_nelma
683
-
export_ps
1608
-
works
-
buildin
-
Export postscript or embedded postscript.
-
gpmi
2992
-
works
-
buildin
- (if gpmi is installed)
-
Scriptable plugin system with about 10 scripting languages supported and dynamic load/unload of scripts that can manipulate the GUI, the board, can implement exporters, etc.
-
import_edif
3578
-
works
-
buildin
-
Import code for netlists in the EDIF format.
-
import_sch
255
-
works
-
buildin
-
Imports element and netlist data from the schematics (or some other source).
-
mincut
886
-
works
-
buildin
-
Use the minimal cut algorithm to indicate shorts: instead of highlighting two random pins/pads, try to highlight the least number of objects that connect the two networks.
-
oldactions
53
-
works
-
disabled
-
Random collection of old/obsolete actions. Bell(): audible feedback; DumpLibrary(): print footprint library on stdout
-
puller
1878
-
works
-
buildin
-
Pull traces to minimize their length.
-
renumber
218
-
works
-
buildin
-
Renumber elements (renaming them) and generate a text file for back annotation.
-
stroke
124
-
partially works (doesn't work with lesstif; works with the gtk hid, but there's no zoom bindings)
-
disabled
- (requires libstroke installed)
-
Gesture recognition with libstroke.
-
toporouter
6161
-
fails
- (infinite loop in gts)
-
disabled
-
Automatically route selected or all rats using a topological algorithm. This is the new autorouter from 2009.
-
-
-If you are interested to help out, please contact me using
- the live chat (CET daytime) or mail to:
-pcb-rnd (at) igor2.repo.hu.
-
-
Contributing as a user
-Using pcb-rnd in production and just reporting bugs is already a huge contribution.
-
-More dedicated users can join in scheduled, systematic testing. Such testing
-is split up into independent chunks that each can be done in an hour.
-
-Even more dedicated users can join developing the documentation.
-
-None of the above requires or assumes any programming skill.
-
-
Contributing as a developer
-
-The project is lead in an autocratic way by Igor2.
-
-Developer freedom taken away:
-
-
the basic concept of pcb-rnd is set and won't change
-
the toolchain is chosen, and won't change; the usual hot topics: svn, scconfig, C.
-
don't add code that restricts usability for others; add code that increases usability for some; thus prefer to add code in plugins!
-
-
-Developer freedom promptly granted:
-
-
svn commit access from day 0
-
work together in trunk/, not alone in a branch
-
pcb-rnd has a strong plugin support; want to implement a strange/controversial feature? In a plugin, almost anything goes
-
especially in plugins, work on whatever you want, even if noone else needs that feature
-
-
-Coding style/indentation: there's an unified style
-in core and core plugins. If you work on those parts, try to stick to it. If you
-are working on a new plugin, it's still the preferred style but you can use
-a different style. However, the rule is that if someone else starts hacking
-that part too, he is allowed to convert the code to the unified format; but
-unified format can not be converted to anything else. So it's a one way
-process which long term grants unified style while not demotivates a plugin
-developer by forcing a style on him in the early, "when the bulk of the code
-is written" phase.
-
-
Index: trunk/doc-rnd/logo.pcb
===================================================================
--- trunk/doc-rnd/logo.pcb (revision 5606)
+++ trunk/doc-rnd/logo.pcb (nonexistent)
@@ -1,91 +0,0 @@
-# release: pcb-rnd 1.1.0
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 15240000nm 15240000nm]
-
-Grid[635000nm 0 0 1]
-Cursor[13335000nm 8890000nm 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[304800nm 228600nm 254000nm 177800nm 381000nm 254000nm]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,254000nm,1999996nm,800100nm,508000nm:Power,508000nm,2199894nm,999998nm,508000nm:Fat,2032000nm,3500120nm,1199896nm,635000nm:Sig-tight,254000nm,1625600nm,800100nm,304800nm"]
-
-Symbol['r' 304800nm]
-(
- SymbolLine[127000nm 889000nm 127000nm 1270000nm 203200nm]
- SymbolLine[127000nm 889000nm 254000nm 762000nm 203200nm]
- SymbolLine[254000nm 762000nm 508000nm 762000nm 203200nm]
- SymbolLine[0 762000nm 127000nm 889000nm 203200nm]
-)
-Symbol['n' 304800nm]
-(
- SymbolLine[127000nm 889000nm 127000nm 1270000nm 203200nm]
- SymbolLine[127000nm 889000nm 254000nm 762000nm 203200nm]
- SymbolLine[254000nm 762000nm 381000nm 762000nm 203200nm]
- SymbolLine[381000nm 762000nm 508000nm 889000nm 203200nm]
- SymbolLine[508000nm 889000nm 508000nm 1270000nm 203200nm]
- SymbolLine[0 762000nm 127000nm 889000nm 203200nm]
-)
-Symbol['d' 304800nm]
-(
- SymbolLine[508000nm 254000nm 508000nm 1270000nm 203200nm]
- SymbolLine[381000nm 1270000nm 508000nm 1143000nm 203200nm]
- SymbolLine[127000nm 1270000nm 381000nm 1270000nm 203200nm]
- SymbolLine[0 1143000nm 127000nm 1270000nm 203200nm]
- SymbolLine[0 889000nm 0 1143000nm 203200nm]
- SymbolLine[0 889000nm 127000nm 762000nm 203200nm]
- SymbolLine[127000nm 762000nm 381000nm 762000nm 203200nm]
- SymbolLine[381000nm 762000nm 508000nm 889000nm 203200nm]
-)
-
-
-Attribute("PCB::grid::unit" "mil")
-Attribute("PCB::conf::editor/buffer_number" "0")
-Attribute("PCB::conf::editor/draw_grid" "true")
-Attribute("PCB::conf::editor/show_solder_side" "0")
-Attribute("PCB::conf::editor/view/flip_x" "0")
-Attribute("PCB::conf::editor/view/flip_y" "0")
-
-Element["" "dip(2)" "rnd" "2*300" 0 6985000nm 6350000nm 635000nm 0 115 ""]
-(
- Pin[7620000nm 0 2540000nm 1270000nm 2692400nm 999998nm "" "2" "thermal(0X,1X)"]
-
- )
-Layer(1 "component")
-(
- Polygon("clearpoly")
- (
- [635000nm 635000nm] [14605000nm 635000nm] [14605000nm 14605000nm] [635000nm 14605000nm]
- )
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
Index: trunk/doc-rnd/hacking/hid_remote/proto_parse.html
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/proto_parse.html (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/proto_parse.html (nonexistent)
@@ -1,38 +0,0 @@
-
-
-Protocol parser state machine of the referece implementation:
-
-Legend:
-
-
yellow boxes are states
-
blue arrows are optional features for a more tolerant parser
-
round nodes are actions that shall be taken
-
arrow with text: execute aciton or switch state if condition is true
-
arrow without text: do this if no other condition is met
-
-
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:
-
-
a boolean indicating whether we are parsing the length or the string (before or after the '=')
-
an integer string length
-
-
-
-
\ No newline at end of file
Index: trunk/doc-rnd/hacking/hid_remote/proto_parse.dot
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/proto_parse.dot (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/proto_parse.dot (nonexistent)
@@ -1,84 +0,0 @@
-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-rnd/hacking/hid_remote/proto_high.html
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/proto_high.html (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/proto_high.html (nonexistent)
@@ -1,224 +0,0 @@
-
-
-
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:
-
-
protver: an integer value; 1 for the current version
-
-
-
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:
-
-
abbrev: unit name abbreviation; e.g. mm or nm or mil
-
-
-
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:
-
-
w: width (x size) in coordinate units
-
h: height (y size) in coordinate units
-
-
-
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:
-
-
x1: left coordinate
-
x2: right coordinate
-
y1: top coordinate
-
y2: bottom coordinate
-
-
-
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:
-
-
name: name of the layer (can be empty)
-
id: unique group ID (decimal integer)
-
flags: a list of 3 items: location, purpose and properites. Each item is a list of values (or an empty list).
-
group: group ID; layers in the same group are turned on/off together and are considered to be on the same physical layer; -1 means not part of any group
-
-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:
-
-
group_id: unique ID of the layer group
-
flags: TODO
-
is_empty: 1 if the layer group may be empty, 0 if the layer is not empty
-
-
-
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:
-
-
ID: integer ID of the GC
-
-
-
clr(gci colorstring)
-Change the color subsequent drawing commands of a given GC will use.
-
-Arguments:
-
-
gci: ID of the GC
-
colorstring: name of the color, specified in the usual "web" format: #rrggbb (with 3 hex numbers)
-
-
-
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:
-
-
gci: ID of the GC
-
style: r for round cap (circle), s for square cap, b for beveled (octagon)
-
-
-
-
linwid(gci width)
-Sets line width (pen tip diameter).
-
-Arguments:
-
-
gci: ID of the GC
-
width: diameter of the circular aperture of the pen in coord units
-
-
-
setxor(gci state)
-Sets whether to perform "xor-drawing" for subsequent drawing commands in
-the selected GC.
-
-Arguments:
-
-
gci: ID of the GC
-
xor: 0 means normal drawing, 1 means xor drawing
-
-
-
-
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:
-
-
gci: ID of the GC
-
x1: 1st endpoint's X coord (in coord units)
-
y1: 1st endpoint's Y coord (in coord units)
-
x2: 2nd endpoint's X coord (in coord units)
-
y2: 2nd endpoint's Y coord (in coord units)
-
-
-
rect(gci x1 y1 x2 y2 filled)
-Draw a rectangle. The rectangle inherits only color from the GC.
-
-Arguments:
-
-
gci: ID of the GC
-
x1: 1st corner X coord (in coord units); x1 <= x2
-
y1: 1st corner Y coord (in coord units); y1 <= y2
-
x2: 2nd corner X coord (in coord units)
-
y2: 2nd corner Y coord (in coord units)
-
filled: 1 if the rectangle should be filled; a non-filled rectanlge is a frame of 1 pixel wide lines
-
-
-
-
fcirc(gci cx cy r)
-Draw a filled circle. The circle inherits only color from the GC.
-
-Arguments:
-
-
gci: ID of the GC
-
cx1: center X coord (in coord units)
-
cy1: center Y coord (in coord units)
-
r: radius (in coord units)
-
-
-
poly(gci len ptlist)
-Draw a filled polygon. The polygon inherits only color from the GC.
-
-Arguments:
-
-
gci: ID of the GC
-
len: number of contour points
-
ptlist: an ordered list of (x y) coordinates (all in coord units)
-
-
-
umask(m)
-"use mask" m. The server uses this message to make an announcement before it
-starts drawing certain things.
-
-Arguments:
-
-
m: mask name:
-
-
off: flush the buffer and return to non-mask operation.
-
-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:
-
-
text-string,
-
generic-list,
-
binary-list.
-
-A binary-list is wrapped in braces {} and its children are:
-
-
binary-string,
-
binary-list.
-
-
-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:
-
-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:
-
-
a binary-string can be only on a binary-list
-
a text-string can be only on a generic-list
-
a generic-list can not be only under a binary-list
-
-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-rnd/hacking/hid_remote/proto_parse.svg
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/proto_parse.svg (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/proto_parse.svg (nonexistent)
@@ -1,597 +0,0 @@
-
-
-
-
-
Index: trunk/doc-rnd/hacking/hid_remote/Makefile
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/Makefile (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/Makefile (nonexistent)
@@ -1,9 +0,0 @@
-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-rnd/hacking/hid_remote/fixlab.sh
===================================================================
--- trunk/doc-rnd/hacking/hid_remote/fixlab.sh (revision 5606)
+++ trunk/doc-rnd/hacking/hid_remote/fixlab.sh (nonexistent)
@@ -1,43 +0,0 @@
-#!/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-rnd/hacking/hid_remote/fixlab.sh
___________________________________________________________________
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property
Index: trunk/doc-rnd/hacking/plugin_core_simple.html
===================================================================
--- trunk/doc-rnd/hacking/plugin_core_simple.html (revision 5606)
+++ trunk/doc-rnd/hacking/plugin_core_simple.html (nonexistent)
@@ -1,59 +0,0 @@
-
-
-
pcb-rnd hacking - simple core plugins
-
-
Introduction
-
-
Setting up a new core plugin
-
-
1. make up a name for the plugin. There are a few conventions. This document will refer to the name as plg, always replace it with your chosen name.
-
2. cd src_plugins; svn mkdir plg
-
3. copy Makefile, Plug.tmpasm and README from another, small plugin, for example from the report plugin (the next points will assume you picked this plugin as the source of the copy)
-
4. edit Makefile: replace report to plg
-
5. edit README; there should be short summary about the purpose of the plugin then "#key: value" pairs for statistics:
-
-
#state: either works or disabled
-
#lstate: if state is disabled, add a new line #lstate: with a few words on why the plugin is disabled
-
#default:disabled or builtin or plugin (this field might be removed later because of redundancy)
-
#implements: the same as the plugin name prefix (see conventions. ) or (feature) for feature plugins; it's redundant but is kept for supporting external plugins
-
sbuildin - unless the user requests otherwise, your plugin is linked into the executable
-
sdisable - unless the user requests otherwise, your plugin is not compiled (recommended until the plugin gets some user testing)
-
splugin - unless the user requests otherwise, your plugin is dynamically linked; not recommended: the policy is to let users explicitly request dynamic linking
-
- The order of entries in the file is the same as the order in the summary table
- at the end of ./configure; insert your plugin in the right group!
-
9. add your plugin to the build list in one of the src_plugins/plugins_*.tmpasm files; choose the file that lists plugins similar to yours.
-
10. run ./configure --buildin-plg
-
11. run make to see if it compiles and test
-
(12. while developing, you can run make from src_plugins/plg - if
- your plugin is a builtin, it will recompile pcb-rnd. For some of us it's convenient
- to run make in the same directory where all the source files are.)
-
-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-rnd/hacking/c89.html
===================================================================
--- trunk/doc-rnd/hacking/c89.html (revision 5606)
+++ trunk/doc-rnd/hacking/c89.html (nonexistent)
@@ -1,14 +0,0 @@
-
-
-
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:
-
-
commengt: always use /* */, never //
-
don't mix variable declaration with code - open a new {} block, which will also scope your new variables, or better yet, split up the function into smaller, static functions, the compiler will inline them anyway
-
try to avoid vararg macros, use vararg functions instead
-
Index: trunk/doc-rnd/hacking/releasing.txt
===================================================================
--- trunk/doc-rnd/hacking/releasing.txt (revision 5606)
+++ trunk/doc-rnd/hacking/releasing.txt (nonexistent)
@@ -1,11 +0,0 @@
-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-rnd/hacking/src/data1.dot
===================================================================
--- trunk/doc-rnd/hacking/src/data1.dot (revision 5606)
+++ trunk/doc-rnd/hacking/src/data1.dot (nonexistent)
@@ -1,59 +0,0 @@
-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-rnd/hacking/src/Makefile
===================================================================
--- trunk/doc-rnd/hacking/src/Makefile (revision 5606)
+++ trunk/doc-rnd/hacking/src/Makefile (nonexistent)
@@ -1,2 +0,0 @@
-../data1.png: data1.dot
- dot -Tpng $^ > $@
Index: trunk/doc-rnd/hacking/plugin_naming.html
===================================================================
--- trunk/doc-rnd/hacking/plugin_naming.html (revision 5606)
+++ trunk/doc-rnd/hacking/plugin_naming.html (nonexistent)
@@ -1,12 +0,0 @@
-
-
-
pcb-rnd hacking - plugin naming conventions
-
-
export plugins start with export_; these render to a non-native format that can not be then loaded
-
native formats are prefixed with io_; even if your plugin can now only load or save, if it's possible to do a load-save-load round-trip without data loss, it's an io_
-
interactive, often GUI, frontends are prefixed with hid_
-
footprint access plugins start with fp_
-
anything else is considered a feature plugin and has no specific prefix.
-
-
-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:
-
-
layer stack
-
netlist
-
editor settings (e.g. routing styles, which layers are visible)
-
metadata (such as name of the author, size of the board).
-
-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:
-
-
per-layer objects (e.g. lines, arcs, polygons)
-
global objects (e.g. elements, vias)
-
temporary logical connections (rat lines)
-
-
-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:
-
-
as of now pcb-rnd does not have Z-coordinate: layers have no thickness;
-
substrate is not represented at all in the layers stack.
-
-
-The location of a layer group on of:
-
-
top (component) side
-
bottom (solder) side
-
inner (signal)
-
global (affects all locations, e.g. the outline layer for routing)
-
-
-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:
-
-
they are not part of the layer group system
-
unlike explicit layers they have fixed index (+1 and +2 beyond the last explicit layer)
-
created an moved by the core automatically
-
can not be removed
-
-
-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:
-
-
solder mask - no layer struct, calculated on-the-fly from pad data
-
paste - no layer struct, calculated on-the-fly from pad data
-
fab - no layer struct, calculated on-the-fly from drill/hole data
-
-
-
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-rnd/hacking/obj_func_naming.txt
===================================================================
--- trunk/doc-rnd/hacking/obj_func_naming.txt (revision 5606)
+++ trunk/doc-rnd/hacking/obj_func_naming.txt (nonexistent)
@@ -1,83 +0,0 @@
-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-rnd/hacking/import.html
===================================================================
--- trunk/doc-rnd/hacking/import.html (revision 5606)
+++ trunk/doc-rnd/hacking/import.html (nonexistent)
@@ -1,64 +0,0 @@
-
-
-
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:
-
-
lists for layer-independent objects (e.g. rat lines, vias, elements)
-
number of layers in use (LayerN) and an array of layers (see later)
-
rtree structures - these are used for looking up objects for locations
-
-Each layer is a LayerType structure. A layer has the following fields:
-
-
lists for lines, texts, arcs, polygons
-
some generic layer attributes (colors, flags, key-value pairs)
-
an rtree struct for each object type.
-
-
-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-rnd/hacking/data1.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/hacking/data1.png
===================================================================
--- trunk/doc-rnd/hacking/data1.png (revision 5606)
+++ trunk/doc-rnd/hacking/data1.png (nonexistent)
Property changes on: trunk/doc-rnd/hacking/data1.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/myfeature.html
===================================================================
--- trunk/doc-rnd/myfeature.html (revision 5606)
+++ trunk/doc-rnd/myfeature.html (nonexistent)
@@ -1,69 +0,0 @@
-
-
- pcb-rnd - my feature
-
-
-
-
-
-
-
-
pcb-rnd - how to get my favorite feature implemented
-
-The list below is sorted: top items have higher priority, but you
-are free to choose any.
-
-
1. If you are a programmer with free time to spend
-Read the contribution howto and join the project.
-You are welcome to work only on the feature you are interested in. You get
-all the support (e.g. for understending the API, to get a blank plugin
-set up so you need to fill in only the feature-specific parts, etc.). Success
-rate shoudl be near to 100%.
-
-
2. If you are not a programmer and have free time
-You can join and work on things you don't need that much, but others do.
-This will build your reputation in the community which in turns encourages
-others to implement your favorite feature even if they wouldn't do it for
-themselves. The success rate is somewhat more random, obviously.
-
-
3. If you don't have free time
-Consider donation: buy someone else's time. To do so, contact me
-(see the contribution howto page). Since
-you don't need to cover all costs and the hourly rates are much lower
-on a pet project, and your feature may be simpler than it looks, and
-someone who already knows the code also saves the learning cureve, it may
-all be cheaper than you think. The success rate should be close to 100%.
-
-However, this is a last resort solution, the above ones are clearly preferred.
-
-
-
4. If you don't have anything to contribute with
-[DEL:Vote for it in the
-feature poll. If your feature is not there, ask on the mailing list.
-Chance for success: if it's a popular demand on the feature poll, chances
-are somewhat good. Else chances are very low, but not zero.:DEL]
-
-Because of 100% passivity of the geda community, I decided not to spend more
-time on community-related tasks. The poll is there, you can use it,
-but you will have to orgnaize at least 5 active, capable users who are
-commited enough to spend significant time on testing/supporting development.
-I will consider implementing your feature only if you can bring and keep
-those people motivated and active.
-
-
5. If you tried everything, even point 4. and all failed...
-Complain loudly on the mailing list, advertise your opinion, try pushing
-the thing - a.k.a. go trolling. Success rate is exactly 0%,
-you make a lot of good friends enemies that will make it harder
-to ask or contribute later for another feature, but it may make you feel
-better. </irony>.
-
Index: trunk/doc-rnd/distros.txt
===================================================================
--- trunk/doc-rnd/distros.txt (revision 5606)
+++ trunk/doc-rnd/distros.txt (nonexistent)
@@ -1,47 +0,0 @@
-How to request packaging (distros sorted by popularity, 2016):
-
-Ubuntu:
- easiest is to get in Debian, Ubuntu picks up packages from sid
- alternative: ubuntu-devel-discuss@lists.ubuntu.com (pending)
- alternative: https://bugs.launchpad.net/ubuntu/+filebug?no-redirect&field.tag=needs-packaging
-
-linux mint
- https://blueprints.launchpad.net/linuxmint
- (same maintainer as debian?)
-
-slackware:
- Promised (AFK, ask again in 3rd week of sept)
- geda/pcb maintainer: pfeifer[dot]felix[at]googlemail[dot]com (sent mail)
- https://slackbuilds.org/guidelines/
- needs an existing package
- since the slackbuild needs slackware's pkgtools usually at the end of a ./configure --prefix=/usr --extrastuff..make.. make install DESTDIR=/tmp/NAMEOFPACKAGE..cd /tmp/NAMEOFPACKAGE..makepkg -l y -c n ../NAMEOFPACKAGE-123.txz
- installwatch can build a package
- check out #slackbuilds
-
-Debian:
- Bdale?
- (alternative: pkg-electronics-devel@lists.alioth.debian.org - pending)
- (alternative: RFP through reportbug)
-
-fedora:
- https://fedoraproject.org/wiki/Package_maintainers_wishlist?rd=PackageMaintainers/WishList
- (wrote mail to cicku)
-
-OpenSuse:
- adrian [at] suse.de (mail sent)
-
-Arch:
- DONE! needs to be modularized
- Kyle Keen (mail sent)
-
-Manjaro:
- Same as arch
-
-----
-FreeBSD:
- hrs [at] freebsd.org (Hiroki Sato - mail sent)
-
-OpenBSD:
- andreas.bihlmaier [at] gmx.de -> ENOTIME, he suggests ports@openbsd.org
-
-
Index: trunk/doc-rnd/query/tutor_cli.html
===================================================================
--- trunk/doc-rnd/query/tutor_cli.html (revision 5606)
+++ trunk/doc-rnd/query/tutor_cli.html (nonexistent)
@@ -1,168 +0,0 @@
-
-
-
-
advanced search, command line tutorial: query language
-
-
scope
-
-pcb-rnd from version 1.1.3 features a flexible advnced search that helps
-the user selecting/unselecting objects that match a given logical expression.
-The core of the feature is the pcb-rnd query language. The same language
-is used in the programmable DRC (see also:
-a more formal description of the language).
-
-The current document is a walk through of the practical aspects of the
-language. It starts with the simplest examples while working towards more
-complex cases.
-
-A limited version of the functionality is accessible through a GUI
-wizard when using the GTK HID. A separate
-tutorial is dealing with that feature.
-
-
Actions
-The query(act, expr) action creates the list called "@", which contains all
-objects of the design. Then it iterates over this list (if needed) and
-evaluates the query expression on each object. For each evaluation "act"
-is performed; "act" is one of:
-
-
select - add the matching object to the selections if expr evaluated to true
-
unselect - remove the matching object from the selections if expr evaluated to true
-
eval - print the result of the expression to stdout
-
dump - this inhibits evaluating; it compiles the expression and dumps the parse tree (useful for debugging)
-
-
-The symbol @ in the query represents the iterator, or in other words,
-the current object we are checking. The engine iterates over all
-copper objects, silk objects, pins, holes, layers and nets. A simple query
-that selects all objects looks like this:
-
-query(select, '@')
-
-The actual query experssion was a single @ in this case. This made
-the iteration happen, got the expression evaluated one each object. The
-result of each evaluation was the given object. Since these objects
-were all existing, valid objects, they were taken as logical value TRUE,
-thus for each the add-to-selection was performed.
-
-Note: it's usually a good idea to write the expression in single quotes, because
-it may contain commas, double quotes and parenthesis that pcb-rnd's action parser may
-take as action syntax.
-
-The same expression can ran with eval would print the result of each
-evaluation:
-
-query(eval, '@')
-
-This is visible on the terminal pcb-rnd was started from - on X, it's a good
-idea to start a terminal and run pcb-rnd from that instead from a menu or
-icon. The rest of this tutorial will use the eval query because it's easier
-to include the result of an eval than of a selection. Most examples will
-specify the query expression only, without quotes - the reader should
-add the query(eval, ' ') part.
-
-
iteration vs. evaluate once
-If an expression does not reference the @ object, no iteration is performed
-and the expression is ran only once:
-
-query(eval, '1')
-
-This will calculate the value of 1 and prints it to the standard output. Since
-theres no iteration, this can not result in changes in selection. However,
-it makes it easy to demonstrate some basic concepts of the query language.
-
-Note: if @ is present multiple times in the expression, it's still only
-one loop over all objects. When evaluating the expression for a given object,
-all instances of @ are substituted with the same object in that iteration.
-
-
-
grammar: arithmetics and logics
-For example the integer and floating point numbers and the usual
-arithmetic and logical operators work as expected:
-
-
-
expression
result
explanation
-
42
42
the integer value 42
-
3.14
3.14
the floating point value 3.14
-
10 mil
254000
a number with a unit suffix is converted to pcb-rnd's internal coordinate unit (nanometers)
-
1+2
3
sum of 1 and 2
-
2*4
8
multiplication
-
47/4
11
integer division (because both operands were integers)
-
47/4.0
11.75
floating point division (because at least one of the operands was a float)
-
(1+2)*5
15
parenthesis works as usual
-
1 && 0
0
logical AND - the result is 1 if both operands were TRUE, 0 else
-
1 || 0
1
logical OR - the result is 1 if either operand was TRUE, 0 else
-
!2
0
logical NOT - 2 is non-zero, so it is TRUE, negate this to get the result (FALSE, which is 0)
-
4 > 2
1
because four is greater than two; all the usual relational operats work: == is equal, != is not-equal, <, <=, > and >=.
-
-
-
grammar: object properties
-Object have named properties, e.g. the thickness of a line (or arc, or
-trace in general) is called ".thickness", so the thickness of
-the current object is:
-
- @.thickness
-
-
-Next, we can already select all traces thicker than 10 mil:
-
- query(select, '@.thickness > 10 mil')
-
-
-Because logical expressions are available, it's easy to select all medium-thick
-lines:
-
-But how comes an expression like '@.thickness > 10 mil' works while
-@ iterates over non-trace objects, like layers, nets or elements that
-clearly have no thickness?
-
-The answer is the invalid value, which is neither true nor false. If
-a property does not exist in a given object, the result is the invalid value
-or invalid for short. The invalid is treated specially:
-
-
in arithmetic operations it propagates: if either operand is invalid, the result is invalid, e.g. 1+invalid = invalid; this affects +, -, *, / and all the relational operators
-
in binary logic operations (&& and ||), it is ignored: it is assumed to be true in a && and false in a || so the outcome depends on the other operand
-
in logical NOT (!), TODO
-
-When @ refers to a non-trace object, @.thickness is invalid and
-'@.thickness > 10 mil' is evaluated t invalid. If the result is not TRUE,
-the requested action is not performed.
-
-The invalid value is generated only when the expression is valid but the
-actual object doesn't have the feature needed. If the expression is wrong,
-an error is generated and the expression stops evaluating immediately.
-
-
grammar: more properties
-Some properties are a single numeric value, like thickness, or the
-.name of a layer (which is a string) but others are objects. For
-example the .layer property of a line or arc refers to the layer
-object the given line or arc is drawn on. These in turn can be combined,
-and the "name of the layer the current object is on":
-
- @.layer.name
-
-
-Referencing non-existing properties yields an error, e.g. @.thickness.layer
-is an error - in contrast with @.layer, which may evaluate to the
-invalid value (e.g. for vias or nets, because they don't have layers).
-The difference is that tickness can not have a layer ever (thus is an error)
-while @.layer is either applicable or not, but potentially could work, this
-when it doesn't, it's only an invalid value.
-
-Further useful property combinatons:
-TODO
-
-There is a full list of all properties.
Index: trunk/doc-rnd/windows.txt
===================================================================
--- trunk/doc-rnd/windows.txt (revision 5606)
+++ trunk/doc-rnd/windows.txt (nonexistent)
@@ -1,38 +0,0 @@
-State on windows
-~~~~~~~~~~~~~~~~
-
-Does not work yet. This file documents how far we got. The situation
-is constantly improving.
-
-1. Cross compilation from Linux to win32
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-(developers may need this, if you are an user, skip to 2.)
-
-TODO: deps with mpk
-
-Use mingw and wine:
-
- ./configure --emu="wine cmd /c" --target=i586-mingw32msvc "$@"
-
-(Replace i586- with whatever toolchain prefix you have)
-
-2. download the binary pack
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Temporary URL: http://igor2.repo.hu/tmp/pcb-rnd-pack.zip
-
-Download, unpack, run setup.bat then pcb-rnd.bat
-
-All binaries in the pack are cross-compiled from source, using mingw and
-mpk. All binaries are 32-bit. The pack is self-contained, no gtk or other
-external dependencies.
-
-Known bugs:
- - inserting elements fail (even static ones)
- - no shell and awk in the pack -> parametric footprints fail
- - text (including menu text) doesn't appear on XP
- - no exporters that depend on libgd (png, jpeg, gif, nelma)
-
-Worked on systems:
- - Windows 8.1 pro, Hungarian, 32 bit
- - Windows 7 pro, Hungarian, 64 bit
- - Windows 7 pro, English, 64 bit
Index: trunk/doc-rnd/man/pcb-rnd.1
===================================================================
--- trunk/doc-rnd/man/pcb-rnd.1 (revision 5606)
+++ trunk/doc-rnd/man/pcb-rnd.1 (nonexistent)
@@ -1,47 +0,0 @@
-.\" pcb-rnd - manual
-.\" Copyright (C) 2016 Tibor 'Igor2' Palinkas
-.\"
-.\" This program is free software; you can redistribute it and/or modify
-.\" it under the terms of the GNU General Public License as published by
-.\" the Free Software Foundation; either version 2 of the License, or
-.\" (at your option) any later version.
-.\"
-.\" This program is distributed in the hope that it will be useful,
-.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
-.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-.\" GNU General Public License for more details.
-.\"
-.\" You should have received a copy of the GNU General Public License along
-.\" with this program; if not, write to the Free Software Foundation, Inc.,
-.\" 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-.\"
-.\" Contact: pcb-rnd[removethis]@igor2.repo.hu
-.TH pcb-rnd 1 2016-10-29 "" "pcb-rnd manual"
-.SH NAME
-pcb-rnd - Printed Circuit Board editor
-.SH SYNPOSIS
-.nf
-.sp
-\fBpcb-rnd [\fIoptions\fB] [\fIinputfile\fB]
-.fi
-.SH DECSRIPTION
-
-.BR pcb-rnd
-is a modular PCB editor. The main use is interactive editing. If no \fI-x\fR is specified on the command line, the graphical editor mode is initiated. Automated, headless processing is also possible with \fI-x\fR or \fI--gui batch\fR.
-.SH OPTIONS
-
-
-.TP
-
-.B -x \fIexporter\fR [\fIexportflags] \fIinputfile\fR\fR
-Instead of interactive editing, export the design (loaded from \fIinputfile\fR) to a file using the specified \fIexporter\fR plugin. A list of exporter-specific parameters may follow to control the details of the process.
-.TP
-
-.B --gui \fIhid\fR
-Use the \fIhid\fR plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user intrfaces and "batch" for a headless command-line interface (or automated batch processing).
-.TP
-
-.B -c \fIpath=val\fR
-Set a config node in role CFR_CLI. The path of the node is \fIpath\fR (e.g. editor/grid) and the new value is \fIval\fR (e.g. 5mm).
-.PP
-
Index: trunk/doc-rnd/man/pcb-rnd.1.html
===================================================================
--- trunk/doc-rnd/man/pcb-rnd.1.html (revision 5606)
+++ trunk/doc-rnd/man/pcb-rnd.1.html (nonexistent)
@@ -1,79 +0,0 @@
-
-
-
-
-
pcb-rnd 1
-
2016-10-29
-
pcb-rnd manual
-
-
-
-
-
NAME
-
-pcb-rnd - Printed Circuit Board editor
-
-
-
SYNPOSIS
-
-
-pcb-rnd [options] [inputfile]
-
-
-
-
-
-
DESCRIPTION
-
-pcb-rnd is a modular PCB editor. The main use is interactive editing. If no -x is specified on the command line, the graphical editor mode is initiated. Automated, headless processing is also possible with -x or --gui batch.
-
-
-
-
OPTIONS
-
-
-
-
-
-
-
-x exporter [exportflags] inputfile
-
Instead of interactive editing, export the design (loaded from inputfile) to a file using the specified exporter plugin. A list of exporter-specific parameters may follow to control the details of the process.
-
-
-
--gui hid
-
Use the hid plugin for the "gui" frontend. Common choices are "gtk" or "lesstif" for graphical user intrfaces and "batch" for a headless command-line interface (or automated batch processing).
-
-
-
-c path=val
-
Set a config node in role CFR_CLI. The path of the node is path (e.g. editor/grid) and the new value is val (e.g. 5mm).
-
-
-
-
-
-
pcb-rnd 1
-
2016-10-29
-
pcb-rnd manual
-
-
-
-
Index: trunk/doc-rnd/man/pcb-rnd.1.mml
===================================================================
--- trunk/doc-rnd/man/pcb-rnd.1.mml (revision 5606)
+++ trunk/doc-rnd/man/pcb-rnd.1.mml (nonexistent)
@@ -1,38 +0,0 @@
-pcb-rnd
-1
-2016-10-29
-
- pcb-rnd - Printed Circuit Board editor
-pcb-rnd [options] [inputfile]
-
-
-pcb-rnd is a modular PCB editor. The main use is interactive
-editing. If no -x is specified on the command line, the
-graphical editor mode is initiated. Automated, headless processing
-is also possible with -x or --gui batch.
-
-
-
-
-
- -x exporter [exportflags] inputfile
- Instead of interactive editing, export the design (loaded from
- inputfile) to a file using the specified
- exporter plugin. A list of exporter-specific parameters
- may follow to control the details of the process.
-
-
- --gui hid
- Use the hid plugin for the "gui" frontend. Common
- choices are "gtk" or "lesstif" for graphical user intrfaces
- and "batch" for a headless command-line interface (or automated
- batch processing).
-
-
- -c path=val
- Set a config node in role CFR_CLI. The path of the node is
- path (e.g. editor/grid) and the new value is
- val (e.g. 5mm).
-
-
-
Index: trunk/doc-rnd/man/index.html
===================================================================
--- trunk/doc-rnd/man/index.html (revision 5606)
+++ trunk/doc-rnd/man/index.html (nonexistent)
@@ -1,3 +0,0 @@
-
-
pcb-rnd(1) -- pcb-rnd - Printed Circuit Board editor
-
Index: trunk/doc-rnd/man/gsch2pcb-rnd.1
===================================================================
--- trunk/doc-rnd/man/gsch2pcb-rnd.1 (revision 5606)
+++ trunk/doc-rnd/man/gsch2pcb-rnd.1 (nonexistent)
@@ -1,134 +0,0 @@
-.TH gsch2pcb-rnd 1 "September 25th, 2013" "gEDA Project" 1.8.2.20130925
-.SH NAME
-gsch2pcb-rnd - Update pcb-rnd layouts from gEDA/gaf schematics
-.SH SYNOPSIS
-\fBgsch2pcb-rnd\fR [\fIOPTION\fR ...] {\fIPROJECT\fR | \fIFILE\fR ...}
-.SH DESCRIPTION
-.PP
-\fBgsch2pcb-rnd\fR is a frontend to \fBgnetlist\fR(1) which aids in
-creating and updating \fBpcb-rnd\fR(1) printed circuit board layouts based
-on a set of electronic schematics created with \fBgschem\fR(1).
-
-.PP
-Instead of specifying all options and input gEDA schematic \fIFILE\fRs
-on the command line, \fBgsch2pcb-rnd\fR can use a \fIPROJECT\fR file
-instead.
-
-.PP
-\fBgsch2pcb-rnd\fR first runs \fBgnetlist\fR(1) with the `PCB' backend to
-create a `.net' file containing a \fBpcb-rnd\fR(1) formatted netlist for
-the design.
-
-.PP
-The second step is to run \fBgnetlist\fR(1) again with the `gsch2pcb-rnd'
-backend to find any \fBM4\fR(1) elements required by the schematics.
-Any missing elements are found by searching a set of file element
-directories. If no `.pcb' file exists for the design yet, it is
-created with the required elements; otherwise, any new elements
-are output to a `.new.pcb' file.
-
-.PP
-If a `.pcb' file exists, it is searched for elements with a
-non-empty element name with no matching schematic symbol. These
-elements are removed from the `.pcb' file, with a backup in a
-`.pcb.bak' file.
-
-.PP
-Finally, \fBgnetlist\fR(1) is run a third time with the `pcbpins'
-backend to create a `.cmd' file. This can be loaded into
-\fBpcb-rnd\fR(1) to rename all pin names in the PCB layout to match the
-schematic.
-
-.SH OPTIONS
-.TP 8
-\fB-o\fR, \fB--output-name\fR=\fIBASENAME\fR
-Use output filenames `\fIBASENAME\fR.net', `\fIBASENAME\fR.pcb', and
-`\fIBASENAME\fR.new.pcb'. By default, the basename of the first
-schematic file in the list of input files is used.
-.TP 8
-\fB-d\fR, \fB--elements-dir\fR=\fIDIRECTORY\fR
-Add \fIDIRECTORY\fR to the list of directories to search for PCB file
-elements.
-.TP 8
-\fB-r\fR, \fB--remove-unfound\fR
-Don't include references to unfound elements in the generated `.pcb'
-files. Use if you want \fBpcb-rnd\fR(1) to be able to load the
-(incomplete) `.pcb' file. This is enabled by default.
-.TP 8
-\fB-k\fR, \fB--keep-unfound\fR
-Keep include references to unfound elements in the generated `.pcb'
-files. Use if you want to hand edit or otherwise preprocess the
-generated `.pcb' file before running \fBpcb\fR(1).
-.TP 8
-\fB-p\fR, \fB--preserve\fR
-Preserve elements in PCB files which are not found in the schematics.
-Since elements with an empty element name (schematic "refdes") are
-never deleted, this option is rarely useful.
-.TP 8
-\fB--gnetlist\fR \fIBACKEND\fR
-In addition to the default backends, run \fBgnetlist\fR(1) with `\-g
-\fIBACKEND\fR', with output to `.\fIBACKEND\fR'.
-.TP 8
-\fB--gnetlist-arg\fR \fIARG\fR
-Pass \fIARG\fR as an additional argument to \fBgnetlist\fR(1).
-.TP 8
-\fB--empty-footprint\fR \fINAME\fR
-If \fINAME\fR is not `none', \fBgsch2pcb-rnd\fR will not add elements for
-components with that name to the PCB file. Note that if the omitted
-components have net connections, they will still appear in the netlist
-and \fBpcb-rnd\fR(1) will warn that they are missing.
-.TP 8
-\fB--fix-elements\fR
-If a schematic component's `footprint' attribute is not equal to the
-`Description' of the corresponding PCB element, update the
-`Description' instead of replacing the element.
-.TP 8
-\fB-q\fR, \fB--quiet\fR
-Don't output information on steps to take after running \fBgsch2pcb-rnd\fR.
-.TP 8
-\fB-v\fR, \fB--verbose\fR
-Output extra debugging information. This option can be specified
-twice (`\-v \-v') to obtain additional debugging for file elements.
-.TP 8
-\fB-h\fR, \fB--help\fR
-Print a help message.
-.TP 8
-\fB-V\fR, \fB--version\fR
-Print \fBgsch2pcb-rnd\fR version information.
-
-.SH PROJECT FILES
-.PP
-A \fBgsch2pcb-rnd\fR project file is a file (not ending in `.sch')
-containing a list of schematics to process and some options. Any
-long-form command line option can appear in the project file with the
-leading `\-\-' removed, with the exception of `\-\-gnetlist-arg',
-`\-\-fix-elements', `\-\-verbose', and `\-\-version'. Schematics should be
-listed on a line beginning with `schematics'.
-.PP
-An example project file might look like:
-
-.nf
- schematics partA.sch partB.sch
- output-name design
-.ad b
-
-.SH ENVIRONMENT
-.TP 8
-.B GNETLIST
-specifies the \fBgnetlist\fR(1) program to run. The default is
-`gnetlist'.
-
-.SH AUTHORS
-See the `AUTHORS' file included with this program.
-
-.SH COPYRIGHT
-.nf
-Copyright \(co 1999-2011 gEDA Contributors. License GPLv2+: GNU GPL
-version 2 or later. Please see the `COPYING' file included with this
-program for full details.
-.PP
-This is free software: you are free to change and redistribute it.
-There is NO WARRANTY, to the extent permitted by law.
-
-.SH SEE ALSO
-\fBgschem\fR(1), \fBgnetlist\fR(1), \fBpcb-rnd\fR(1)
Index: trunk/doc-rnd/man/copyright.mml
===================================================================
--- trunk/doc-rnd/man/copyright.mml (revision 5606)
+++ trunk/doc-rnd/man/copyright.mml (nonexistent)
@@ -1,21 +0,0 @@
-
-pcb-rnd - manual\n
-Copyright (C) 2016 Tibor 'Igor2' Palinkas\n
-\n
-This program is free software; you can redistribute it and/or modify\n
-it under the terms of the GNU General Public License as published by\n
-the Free Software Foundation; either version 2 of the License, or\n
-(at your option) any later version.\n
-\n
-This program is distributed in the hope that it will be useful,\n
-but WITHOUT ANY WARRANTY; without even the implied warranty of\n
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n
-GNU General Public License for more details.\n
-\n
-You should have received a copy of the GNU General Public License along\n
-with this program; if not, write to the Free Software Foundation, Inc.,\n
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.\n
-\n
-Contact: pcb-rnd[removethis]@igor2.repo.hu
-
-pcb-rnd manual
Index: trunk/doc-rnd/man/README
===================================================================
--- trunk/doc-rnd/man/README (revision 5606)
+++ trunk/doc-rnd/man/README (nonexistent)
@@ -1,10 +0,0 @@
-Manual pages are written in the manual markup format and are compiled into
-manual and html using mml. Do not edit the generated manual or html pages.
-
-The generated files are commited in the repository so dependencies are not
-required for casual users to build the project.
-
-The required tools and dependencies are:
- svn://repo.hu/libmawk/trunk
- svn://repo.hu/web3.0/trunk
- svn://repo.hu/shscripts/trunk/manmarkup
Index: trunk/doc-rnd/man/Makefile
===================================================================
--- trunk/doc-rnd/man/Makefile (revision 5606)
+++ trunk/doc-rnd/man/Makefile (nonexistent)
@@ -1,58 +0,0 @@
-# This Makefile is a plain old hand written one; all configuration settings
-# are included from ../../Makefile.conf which is scconfig generated
-
-IN=pcb-rnd.1.mml
-OUT_HTML = pcb-rnd.1.html
-OUT_MAN1 = pcb-rnd.1
-OUT_LINT = pcb-rnd.1.lint
-
-OUTPUT = $(OUT_HTML) $(OUT_MAN1) index.html
-MML = /usr/bin/mml
-
-all: $(OUTPUT)
-
-lint: pcb-rnd.1.lint
-
-.SUFFIXES: .html .mml .lint
-
-.mml.html: .mml_linkmap
- $(MML) -i copyright.mml -f html $< > $@
-
-.mml:
- $(MML) -i copyright.mml -f man $< > $@
-
-.mml_linkmap:
- $(MML) -i copyright.mml -f linkmap $(IN) > $@
-
-index.html:
- @echo "" > $@
- $(MML) -i copyright.mml -f indexhtml $(IN) >> $@
- @echo "" >> $@
-
-clean:
-
-distclean:
-
-genclean:
- rm $(OUTPUT) 2>/dev/null ; true
-
-.mml.lint:
- $(MML) -i copyright.mml -f lint $<
-
-install_:
- $(MKDIR) "$(MAN1DIR)"
- $(CPC) "`pwd`/pcb-rnd.1" "$(MAN1DIR)/pcb-rnd.1"
- $(CPC) "`pwd`/gsch2pcb-rnd.1" "$(MAN1DIR)/gsch2pcb-rnd.1"
-
-uninstall:
- $(RM) "$(MAN1DIR)/pcb-rnd.1"
- $(RM) "$(MAN1DIR)/gsch2pcb-rnd.1"
-
-install:
- make install_ CPC="$(CP)"
-
-linstall:
- make install_ CPC="$(LN)"
-
-include ../../Makefile.conf
-
Index: trunk/doc-rnd/ddrc/requirements.txt
===================================================================
--- trunk/doc-rnd/ddrc/requirements.txt (revision 5606)
+++ trunk/doc-rnd/ddrc/requirements.txt (nonexistent)
@@ -1,23 +0,0 @@
-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-rnd/ddrc/examples1.txt
===================================================================
--- trunk/doc-rnd/ddrc/examples1.txt (revision 5606)
+++ trunk/doc-rnd/ddrc/examples1.txt (nonexistent)
@@ -1,54 +0,0 @@
-# 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-rnd/ddrc/proposal1.txt
===================================================================
--- trunk/doc-rnd/ddrc/proposal1.txt (revision 5606)
+++ trunk/doc-rnd/ddrc/proposal1.txt (nonexistent)
@@ -1,242 +0,0 @@
-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-rnd/Makefile
===================================================================
--- trunk/doc-rnd/Makefile (revision 5606)
+++ trunk/doc-rnd/Makefile (nonexistent)
@@ -1,32 +0,0 @@
-MENU_RES=../src/pcb-menu-gtk.lht ../src/pcb-menu-lesstif.lht
-MENU_RES_MKEY=../src/pcb-menu-mkey.lht
-KEYLIST=../util/keylist.sh
-DEBLIST=../util/devhelpers/deblist.sh
-
-all: keys.html keys_mkey.html features/debian_list.html
- ./Autostyle.sh *.html features/*.html
-
-keys.html: $(MENU_RES) $(KEYLIST)
- $(KEYLIST) $(MENU_RES) > keys.html
-
-keys_mkey.html: $(MENU_RES_MKEY) $(KEYLIST)
- $(KEYLIST) $(MENU_RES_MKEY) > keys_mkey.html
-
-features/debian_list.html: ../debian/control
- $(DEBLIST) < ../debian/control > features/debian_list.html
- ./Autostyle.sh features/debian_list.html
-
-install:
- cd man && make install
-
-linstall:
- cd man && make linstall
-
-uninstall:
- cd man && make uninstall
-
-clean:
- cd man && make clean
-
-distclean:
- cd man && make distclean
Index: trunk/doc-rnd/mac.txt
===================================================================
--- trunk/doc-rnd/mac.txt (revision 5606)
+++ trunk/doc-rnd/mac.txt (nonexistent)
@@ -1,22 +0,0 @@
-State on MacOSX
-~~~~~~~~~~~~~~~
-
-Source releases starting from 1.1.0 should compile and run out-of-the-box.
-
-Requirements for GUI: x11 and gtk+
- - X11 server and client libraries for OS X are available from the XQuartz
- download and install
- - gtk+ is available from brew
- * brew install dependencies (gtk+ and libgd) with the following commands
- brew install libgd
- brew install gtk+
- * if you want to use gEDA with PCB-RND you may want to install it as well
- via brew
- brew install homebrew/science/geda-gaf
-
-Known issues:
- - application window opens behind other windows; it seems to be a gtk bug
- that can not be worked around from the application
- - slow rendering and error messages about invalid numerics on the console
-
-Considerations listed in ../INSTALL apply.
Index: trunk/doc-rnd/logo256.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/logo256.png
===================================================================
--- trunk/doc-rnd/logo256.png (revision 5606)
+++ trunk/doc-rnd/logo256.png (nonexistent)
Property changes on: trunk/doc-rnd/logo256.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/vianudge.txt
===================================================================
--- trunk/doc-rnd/djopt/vianudge.txt (revision 5606)
+++ trunk/doc-rnd/djopt/vianudge.txt (nonexistent)
@@ -1,3 +0,0 @@
-Looks for vias where all traces leave in the same direction. Tries to
-move via in that direction to eliminate one of the traces (and thus a
-corner).
Index: trunk/doc-rnd/djopt/orthopull.out.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/orthopull.out.png
===================================================================
--- trunk/doc-rnd/djopt/orthopull.out.png (revision 5606)
+++ trunk/doc-rnd/djopt/orthopull.out.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/orthopull.out.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/unjaggy.txt
===================================================================
--- trunk/doc-rnd/djopt/unjaggy.txt (revision 5606)
+++ trunk/doc-rnd/djopt/unjaggy.txt (nonexistent)
@@ -1,2 +0,0 @@
-Looks for corners which could be flipped to eliminate one or more
-corners (i.e. jaggy lines become simpler).
Index: trunk/doc-rnd/djopt/debumpify.pcb
===================================================================
--- trunk/doc-rnd/djopt/debumpify.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/debumpify.pcb (nonexistent)
@@ -1,89 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[0 5000 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-Attribute("PCB::grid::unit" "mm")
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 17500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 117500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-Layer(1 "component")
-(
- Line[23405 32500 30000 32500 1000 4000 "clearline"]
- Line[92500 32500 111595 32500 1000 4000 "clearline"]
- Line[30000 32500 30000 22500 1000 4000 "clearline"]
- Line[30000 22500 37500 22500 1000 4000 "clearline"]
- Line[37500 22500 37500 32500 1000 4000 "clearline"]
- Line[37500 32500 47500 32500 1000 4000 "clearline"]
- Line[47500 32500 57500 22500 1000 4000 "clearline"]
- Line[57500 22500 67500 22500 1000 4000 "clearline"]
- Line[67500 22500 77500 32500 1000 4000 "clearline"]
- Line[77500 32500 82500 32500 1000 4000 "clearline"]
- Line[82500 32500 85000 22500 1000 4000 "clearline"]
- Line[90000 22500 92500 32500 1000 4000 "clearline"]
- Line[85000 22500 90000 22500 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
- Text[30000 5000 0 105 "90" "clearline"]
- Text[60000 5000 0 105 "45" "clearline"]
- Text[82500 5000 0 105 "rand" "clearline"]
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/Post.html
===================================================================
--- trunk/doc-rnd/djopt/Post.html (revision 5606)
+++ trunk/doc-rnd/djopt/Post.html (nonexistent)
@@ -1,4 +0,0 @@
-
auto
run all the above except miter; run them multiple times until there's no more change possible
-
-The different types of optimizations change your board in order to
-reduce the total trace length and via count. Each optimization is accessible
-using an argument, e.g. djopt(miter). The basic actions have to be run multiple
-times as each iteration will change the design making new changes possible for
-subsequent iterations with the same or other actions.
-
-Click on the images to download the example .pcb design.
-
-
-
-The different types of optimizations change your board in order to
-reduce the total trace length and via count. Each optimization is accessible
-using an argument, e.g. djopt(miter). The basic actions have to be run multiple
-times as each iteration will change the design making new changes possible for
-subsequent iterations with the same or other actions.
-
-Click on the images to download the example .pcb design.
-
-
-
argument name
description
example in
example out after 1st iteration
-
debumpify
-Looks for U-shaped traces (with 90 degree corners) that can be shortened
-or eliminated.
-
-
miter
-Replaces 90 degree corners with a pair of 45 degree corners, to reduce
-RF losses and trace length.
-
-
orthopull
-Looks for chains of traces all going in one direction, with more
-traces orthogonal on one side than on the other. Moves the chain in
-that direction, causing a net reduction in trace length, possibly
-eliminating traces and/or corners.
-
-
unjaggy
-Looks for corners which could be flipped to eliminate one or more
-corners (i.e. jaggy lines become simpler).
-
-
vianudge
-Looks for vias where all traces leave in the same direction. Tries to
-move via in that direction to eliminate one of the traces (and thus a
-corner).
-
-
viatrim
-Looks for traces that go from via to via, where moving that trace to a
-different layer eliminates one or both vias.
-
-
auto
run all the above except miter; run them multiple times until there's no more change possible
-
-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):
-
-
1. design
-
-
1.1. modularity, aka. toolkit approach
-
1.2. flexibility (trough attributes)
-
1.3. one schematics file is one sheet
-
1.4. multi page projects (hierarchic, flat)
-
1.5. data is in structured text files (no builtin sql support in core)
-
1.6. * the concept of a "project"; it's optional, tools can work on a set of schematics files _or_ on a complete project
-
1.7. * nets and components are uniquely identifiable using the same identifiers by all projects
-
1.8. * no excess "smartness" in the GUI editor: no slotting, no pin numbering, no auto renumbering, etc; these all should be done in the netlist layer and results fed back to the editor
-
1.9. * direct, bidirectional communication between the editor (GUI) and the netlist layer without any integration of the two, through simple and clean API, keeping both parts replaceable; attributes cschem got back from the netlister are "volatile": not saved, do not override attributes provided by the user
-
1.10. * less format-specific tricks built into the GUI code, more generic approaches (e.g. a search is a search, not a search-for-text-attribute and results on the result lists are any object of the design)
-
1.11. * slotting, pin mapping, device mapping are in backends
-
1.12. * back annotation should not be any harder than forward annotation
-
1.13. * since a lot of info is invented in backends, not in the GUI (e.g. pin numbers, when slotting), the GUI needs to be able to switch between "views": what (combination of) backend(s) to get these info from; Note: this would also provide an interactive DRC on the GUI with the DRC still implemented in the netlister!
-
1.14. * the scriptable plugin system is based on GPMI from the start to guarantee the tool is not tied to any one specific scripting engine or scripting language
-
-
2. implementation
-
-
2.1. a core library that does common things like figuring what objects are connected with net lines
-
2.2. the simple GUI editor should provide the frame; exotic functions should come from user plugins
-
2.3. a simple netlister that provides only generic (* absolutely no backend specific) queries; actual backends are implemented as plugins
-
2.4. * the core library and the netlister and the GUI core are all implemented in plain C:
-
-
2.4.1. * no dependency on any specific scripting engine or scripting language; no core functionality implemented in anything else but C
-
2.4.2. * no dependency on big "solves-everything" libraries (e.g. no glib or cairo dependency)
-
2.4.3. * the actual GUI is behind the plugin system (like PCB's HIDs)
-
2.4.4. * the first gui, in accordance with the no big libraries, will not be gtk or qt but sdl2 based; this would guarantee to have a front end that doesn't need to be rewritten every 5 years just for the sake of the rewrite
-
2.4.5. * scconfig instead of autotools: smaller, easier to maintain, works better outside of the gnu-win32 world
-
-
-
3. project management
-
-
3.1. automatic tests wherever possible, as early as possible
-
3.2. * VCS: simple, centralized svn with straight linear developement, actively trying to avoid branching
-
3.3. * near-zero-administration releases with svn commits
-
3.4. * users should be able to submit bug reports anonymously, without having to register, without having to run javascript, java applet, flash, etc.
-
-
-
-
-
-There are a lot of open questions:
-
-
q1. how buses should work
-
q2. how slotting should work (but at least we can have alternatives here)
-
q3. how hierarchical design should work
-
q4. * how the GUI should display large amount of attributes without making the whole page an unreadable mess
-
q5. flat vs. non-flat netlists - if turns out it's not just an implementation detail in a netlister backend
-
q6. * whether project file format is a custom format or just a top sch page referencing other sch pages - pcb-rnd is leading here, there is an optional project file format already defined, so this is more or less decided
-
-
-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:
-
-
-
-
the footprint family is a series of footprints that can be generated
-using the same code, with changing some base properties (e.g. number of
-pins)
-
-
dimensions and other properties can be calculated from the base
-properties with reasonable formulas and conditional code; e.g. sot* is not
-a good candidate for generation, as sot23 or sot89 can not be generated
-from some common anestor by varying one or two parameters, but would need
-a large table that translates package name to a pattern - easier to keep
-those in static footprint files
-
-
has a reasonable amount of existing variations; e.g. it is not worth
-writing a generator for the dsub family because there are only a few of
-them in common use (db9, db15, db25, and maybe db37).
-
-
preferably a link to a datasheet that shows at least 3 members of the
-family; if that's not possible, separate datasheets describing at least 3
-members of the family.
-
-
-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.
-
-
-
-
-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.
-
-
-
-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!)
-
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
-
-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:
-
-
it should have a concept of an unwanted pin-network connection; a connection
- becomes unwanted only when the back annotation says so
-
it should be able to mark unwanted connections on the active schematic page
-
it should be able to tell the user if there are unwanted connections on
- any of the pages open
-
it should be able to refresh its idea of unwanted connections while
- schematic pages are open
-
-
-Displaying unwanted connections happen at:
-
-
a pin of a component is connected to a net using a "blue line" net: mark the pin-net connection point
-
a pin is directly connected to another pin, no net line in between: mark the connection point
-
a pin is connected to a net using a pin attribute: mark the pin
-
TODO: are there more?
-
-
-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:
-
-
1. remember or note down which parts to change footprints for
-
2. go back to gschem and change them
-
3. get the changes in pcb (I use gsch2pcb and Makefiles, one step; the import menu is one step too, just another one)
-
4. disperse the new elements
-
5. find where they used to be
-
6. and then do the fiddling to fit them in
-
-
-The new process would be:
-
-
1. get the footprint replaced, in-place; this would already approve the
- change and there'd be a command for it in the patch table
-
2. do the fiddling to fit the new part in
-
3. do a back annotation
-
(4. optionally, if we go for non-automatic change of attributes in gschem,
- change them manually in gschem, cycling through the affected
- items using some UI feature)
-
-
-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.
-
-
-
-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-rnd/devlog/20160921_gl.html
===================================================================
--- trunk/doc-rnd/devlog/20160921_gl.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160921_gl.html (nonexistent)
@@ -1,56 +0,0 @@
-
-
utilizing the 2d or 3d hardware acceleration of the GPU in drawing
-
transparent copper layers
-
on some CPU+GPU combination the current software rendering is slower than mainline's opengl rendering
-
-
-Why we don't have it:
-
-
I don't have a hardware+driver combination where opengl rendering works at acceptable speed
-
I have no experience with opengl programming
-
I am not much interested in changing any of the above two
-
-
-What's needed:
-
-
1. split the gtk hid into:
-
-
a generic gtk UI feature plugin (menu, widgets, controls, no drawing)
-
a gtk-gdk (software render) HID plugin that depends on the gtk feature plugin
-
an gtk-opengl HID plugin that depends on the gtk feature plugin and on the opengl utility plugin
-
-
2. get scconfig to detect opengl headers/libs
-
3. resurrect the opengl utility plugin
-
4. resurrect the opengl drawing code
-
-
-How we could have it, gtk+gl:
-
-
A. contribute: I can do 1. and 2. so you need to concentrate only on the opengl part (3. and 4.);
-
B. or donation/sponsoration:
-
-
buy the time of a random developer for point 3. and 4.; I can still do 1. and 2. in free time, scheduled with the other pcb-rnd duties
-
buy my time so I don't need to sit in my regular job but have a few days off to do all four points
-
-
-
-How we could have it, long term:
-
-
I plan to write an SDL2 based HID
-
SDL2 has transparent render support for both software and accelerated drawing, the latter probably means 2d hardware acceleration which is probably as good as direct opengl drawing would be
-
-
-What we can't do:
-
-
make transparent layers with the current gtk/gdk software render (too much effort)
-
make transparent layers with lesstif (too much effort)
-
speed up the software render
-
Index: trunk/doc-rnd/devlog/res/20150830b_s6.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s6.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s6.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s6.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s6.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_annot.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_annot.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_annot.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_annot.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_annot.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_annot.dot
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_annot.dot (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_annot.dot (nonexistent)
@@ -1,19 +0,0 @@
-digraph annot {
-
-
- gnetlist [shape=box]
-
- {rank=same pcb gschem spacer1}
-
- spacer1 [style=invisible]
-
- foo [shape=box]
-
- gschem -> gnetlist [label="forward1"]
- pcb -> foo [label="back1"]
-
- gschem->spacer1->pcb [style=invisible arrowhead=none]
-
- gnetlist -> pcb [label="forward2"]
- foo -> gschem [label="back2"]
-}
Index: trunk/doc-rnd/devlog/res/20150830b_s0.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s0.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s0.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s0.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s0.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_s1.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s1.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s1.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s1.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s1.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_s2.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s2.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s2.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s2.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s2.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_s3.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s3.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s3.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s3.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s3.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/20150830b_s4.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s4.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s4.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s4.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s4.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/res/Makefile
===================================================================
--- trunk/doc-rnd/devlog/res/Makefile (revision 5606)
+++ trunk/doc-rnd/devlog/res/Makefile (nonexistent)
@@ -1,4 +0,0 @@
-all: 20150830b_annot.png
-
-%.png: %.dot
- dot -Tpng < $^ > $@
Index: trunk/doc-rnd/devlog/res/20150830b_s5.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/res/20150830b_s5.png
===================================================================
--- trunk/doc-rnd/devlog/res/20150830b_s5.png (revision 5606)
+++ trunk/doc-rnd/devlog/res/20150830b_s5.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/res/20150830b_s5.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20150731a_menu.html
===================================================================
--- trunk/doc-rnd/devlog/20150731a_menu.html (revision 5606)
+++ trunk/doc-rnd/devlog/20150731a_menu.html (nonexistent)
@@ -1,59 +0,0 @@
-
-
-
-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:
-
-
there will be a new menu, called "/Plugins"
-
each plugin should have its own submenu there (gpmi for scripting: "/Plugins/GPMI scripting")
-
each script is just a child of the gpmi plugin so it should have its submenus under "Plugins/GPMI scripting/scriptname"
-
-
-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-rnd/devlog/20160808_model.html
===================================================================
--- trunk/doc-rnd/devlog/20160808_model.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160808_model.html (nonexistent)
@@ -1,101 +0,0 @@
-
-
-
-In a proper model there's no element/footprint. There are a few simple
-primitives and there are groups, like the ones in svg: groups contain
-metadata, primitives and groups.
-
-An element is just a group. The whole design may contain groups of groups
-of groups. A stereo amplifier may be a group for a PSU and two instances
-of a single-channel amp group that match square-unit to square-unit.
-
-What makes up an element now is a refdes, its pins/pads we can identify
-(for the netlist-related things) and the feature that you can drag the
-whole thing as one. A group could do all these as well: refdes is just
-metadata, silk lines are just primitives, pins/pads are just small groups
-of primitives and metadata.
-
-There could be "group types" and type-specific code handling them. In such
-a setup you probably don't need to have a text object: just a group that
-consists of mostly lines (or polygons) and some metadata (the string
-version of the text); the group type would assigns the text-handling code
-with to the group. So for the rest of the code, text is not a special
-thing, not a bounding box, but just a set of primitives. When you edit it,
-you can edit it either line-by-line or as text with the assigned code.
-
-This would allow us to have a very small amount of primitives: line, arc,
-poly, hole (without a ring - a via is just a group of a few primitives).
-Each primitive would have a layer-span field; this would solve the
-blind/buried via question for good. (In theory line and arc could be one
-thing, spline oslt, but I don't think performance penalty is worth that.)
-
-However, this means a total rewrite as almost every non-trivial piece of
-the code depends on the object model, from find/search/drc to the whole
-polygon code, just to name two huge ones. The file format thing is the
-smallest of this all. The only major parts I think we could keep are the
-GUI and the new conf system. At the current rate of development this would
-take more than a year to have a mostly working version and probably yet
-another year to get everything tested out and reach current level of
-service again.
-
-I am not against such a rewrite, but it would really need a very strong
-user/tester backing and maybe more developers than the current amount.
-
-Also, Imagine we'd have a pcb program you couldn't trust on
-anything: e.g. losing your data, generating broken gerber, etc. for a very
-long time...
-
-So I generally agree that we should do this, but for practical reasons I
-am a bit skeptic whether this would work out in the current situation.
-It'd kill any cschem plans for years, and because of the long development
-cycle it would most probably kill pcb-rnd too.
-
-</daydreaming>
-
-
Improper implementation
-
-However, I see an alternative that is not as good as the real thing, but
-might be good enough that users don't see much difference. It's
-possible to implement it step by step, without long years of "nothing
-works as used to" phases. The alternative is:
-
-
-
1. Add io_lihata, first as a second native file format option, but long
-term as the primary file format; it's because we can't really extend the
-code without breaking compatibility with mainline on the .pcb format. In
-other words, we either _pretend_ we are compatible, but using any new
-feature would break compatibility (current state) or we admit that new
-features are implemented only in the lihata syntax and when you save to
-.pcb it's like saving png from gimp, losing some extra layer info. This
-step will happen either way, for other reasons.
-
-
2. rearrange some internals; the core is currently split per operation
-(e.g. there's create.c for creating all sort of objects and remove.c
-for removing them). The new setup should be per object type (e.g. arc.c
-that knows how to create or remove arcs).
-
-
3. Once lihata is in place, we can extend/rewrite some parts. An option
-is to rewrite footprint support to allow them to be sort of a small pcb
-design. So objects on arbitrary layers, footprint-in-footprint, etc.
-
-
4. When 3. is done, we could extend element handling so that pcb-rnd knows
-which element is there for why. So you could have some real elements, with
-refdes, part of the netlist, etc, but you could also do a panelization as
-a matrix of full pcb designs place like if they were elements.
-
-
-This 3.,4. would not be the same as building up everything from generic
-atoms, but would be close to it and would be much simpler to implement
-(still a big one, tho). I believe in practice, for end users, it would
-probably be 99% the same as the proper solution.
-
-I believe 3.,4. would be more or less the pcb-rnd equivalent of gschem's
-implementation of schematics and symbols with about the same level of
-generalism. Not perfect, but maybe good enough.
Index: trunk/doc-rnd/devlog/20150820b_qf.html
===================================================================
--- trunk/doc-rnd/devlog/20150820b_qf.html (revision 5606)
+++ trunk/doc-rnd/devlog/20150820b_qf.html (nonexistent)
@@ -1,27 +0,0 @@
-
-
-The next group of footprints I decided to generate are qfn(), tqfp(), lqfp().
-The generic set of rules for these footprints is:
-
-
there is a virtual rectangle that forms rows of pads
-
pads are evenly spaced among the edges of that rectangle
-
pin numbering is counter-clockwise
-
the body of the part may be inside of the rectangle or may extend over the pads
-
-
-
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-rnd/devlog/20150820a_dimensions.html
===================================================================
--- trunk/doc-rnd/devlog/20150820a_dimensions.html (revision 5606)
+++ trunk/doc-rnd/devlog/20150820a_dimensions.html (nonexistent)
@@ -1,24 +0,0 @@
-
-
-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:
-
-
add dimension lines for dimension type input parameters
-
add dimension lines for calculated dimensions if they are likely to be informative and be included in the datasheet
-
-
-
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-rnd/devlog/20160826_virtusers.html
===================================================================
--- trunk/doc-rnd/devlog/20160826_virtusers.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160826_virtusers.html (nonexistent)
@@ -1,65 +0,0 @@
-
-
-
-Pcb-rnd has an pulled-by-users policy on deciding what features to implement.
-Below I try to explain how we ended up using this policy.
-
-
Past: offer, virtual users
-
-When I started pcb-rnd, although I published it, I didn't think anyone else
-would use it. It was just about having mainline with different default
-settings.
-
-Later on I added a few features, and pcb-rnd slowly became much more than
-just different defaults. I felt other users may find the new features useful,
-so I had put it on offer: advertised the repository. I thought users
-would download and try the software. Judging from the feedback, they didn't. I
-didn't mind, becuase I was working on features I needed, to get pcb-rnd do what
-I wanted: I was my own target audience and anyone else trying pcb-rnd could
-only be a side effect. Until when I ran out of features because it already
-had everything I needed.
-
-The next step was to implement features for other users. Between summer
-of 2015 and summer of 2016, I tried to be a bit more proactive: made
-public polls to map what users needed and tried to focus implementing
-those features. This did not bring too many users either.
-
-This was when I realized what was really happening: I was offering
-features for virtual users, addressing my communication to the wide
-auidence. Noone really felt it was for him. Even if he was complaining about
-a missing feature in pcb and a few days later I announced the fix in pcb-rnd, it
-was not specifically for him, but for the Greater Good.
-
-Virtual users nearly never became real users. My conclusion was that there
-was no point in implementing features for virtual users as noone ever would
-use those features.
-
-
Present: pull, active users
-Mid summer 2016, I switched strategy. Instead of polling the crowd, I picked
-a few users with known feature requests and asked them if they were willing to
-test pcb-rnd if I implemented their feature. More than half of them said yes
-and many of them got hooked up. They all became productive, active members
-of the pcb-rnd community.
-
-Learning from this experiece, the new strategy of pcb-rnd is as follows:
-
-
pull instead of offer: do not hope a new feature would attract users,
- rather arrange active users who then pull the project with their
- feature requests;
-
do not invest too much time in anything that is not currently pulled
- by actual, existing, active users; rather invest that time in fulfilling
- the needs of already existing users
-
reaching 100 users with an average of 0.1% activity will result in
- 0 active useres whereas reaching only 10 users with 30% activity
- will result in 3 active users; thus a small active communit around
- pcb-rnd is more efficient than the much larger geda community;
-
users really appreciate fast response on bugreports and feature requests.
- Instead of trying to impress virtual users, rather keep already interested
- users happy.
-
-
-
-
-
Index: trunk/doc-rnd/devlog/20162601/poll.csv
===================================================================
--- trunk/doc-rnd/devlog/20162601/poll.csv (revision 5606)
+++ trunk/doc-rnd/devlog/20162601/poll.csv (nonexistent)
@@ -1,10 +0,0 @@
-0,50,yes,yes,no,no,no,1,2,Linux
-10,40,no,n/a,no,yes,n/a,20,2,Linux
-0,5,n/a,no,no,no,no,20,4,Linux
-5,20,no,no,no,yes,no,5,20,Linux
-0,0,n/a,n/a,no,no,no,10,0,Linux
-0,80,yes,yes,no,no,no,15,0,Linux
-50,80,no,no,no,yes,n/a,30,100,OSX
-20,75,no,no,no,yes,yes,15,3,Linux
-0,8,yes,yes,yes,yes,no,2,1,Linux
-0,2,yes,yes,no,no,no,8,4,Linux
Index: trunk/doc-rnd/devlog/20162601/poll.tsv
===================================================================
--- trunk/doc-rnd/devlog/20162601/poll.tsv (revision 5606)
+++ trunk/doc-rnd/devlog/20162601/poll.tsv (nonexistent)
@@ -1,10 +0,0 @@
-0 50 yes yes no no no 1 2 Linux
-10 40 no n/a no yes n/a 20 2 Linux
-0 5 n/a no no no no 20 4 Linux
-5 20 no no no yes no 5 20 Linux
-0 0 n/a n/a no no no 10 0 Linux
-0 80 yes yes no no no 15 0 Linux
-50 80 no no no yes n/a 30 100 OSX
-20 75 no no no yes yes 15 3 Linux
-0 8 yes yes yes yes no 2 1 Linux
-0 2 yes yes no no no 8 4 Linux
Index: trunk/doc-rnd/devlog/20162601/header.csv
===================================================================
--- trunk/doc-rnd/devlog/20162601/header.csv (revision 5606)
+++ trunk/doc-rnd/devlog/20162601/header.csv (nonexistent)
@@ -1 +0,0 @@
-1. How many of your boards REQUIRE burried or blind vias? [percentage],2. How many of your boards could BENEFIT burried or blind vias? [percentage],3. When your board REQUIRED them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no],4. When your board could BENEFIT using them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no],5. Have you ever tried pcb-rnd? [yes/no],6. Would you try pcb-rnd if it offered blind/burried vias? [yes/no],7. Would you consider switching to pcb-rnd if it offered blind/burried vias? [yes/no],8. Approximately how many boards have you done so far with pcb (pcb mainline/branches/forks included, using gschem/gnetlist not required)? "1 board done" means you had one or more physical copies of the board. [rough estimation, positive integer],9. Approximately how many boards have you done with other packages? [rough estimation, positive integer],10. What OS would you prefer to do your pcb layouts on (assuming your favorite layout tool is/would be available on it)? [one of: (GNU/)Linux, *BSD, OSX, windows, other; if you like more, select the one you would spend most time on!],,
\ No newline at end of file
Index: trunk/doc-rnd/devlog/20162601/header
===================================================================
--- trunk/doc-rnd/devlog/20162601/header (revision 5606)
+++ trunk/doc-rnd/devlog/20162601/header (nonexistent)
@@ -1,11 +0,0 @@
-1. How many of your boards REQUIRE burried or blind vias? [percentage]
-2. How many of your boards could BENEFIT burried or blind vias? [percentage]
-3. When your board REQUIRED them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no]
-4. When your board could BENEFIT using them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no]
-5. Have you ever tried pcb-rnd? [yes/no]
-6. Would you try pcb-rnd if it offered blind/burried vias? [yes/no]
-7. Would you consider switching to pcb-rnd if it offered blind/burried vias? [yes/no]
-8. Approximately how many boards have you done so far with pcb (pcb mainline/branches/forks included, using gschem/gnetlist not required)? "1 board done" means you had one or more physical copies of the board. [rough estimation, positive integer]
-9. Approximately how many boards have you done with other packages? [rough estimation, positive integer]
-10. What OS would you prefer to do your pcb layouts on (assuming your favorite layout tool is/would be available on it)? [one of: (GNU/)Linux, *BSD, OSX, windows, other; if you like more, select the one you would spend most time on!]
-
Index: trunk/doc-rnd/devlog/20162601/poll.html
===================================================================
--- trunk/doc-rnd/devlog/20162601/poll.html (revision 5606)
+++ trunk/doc-rnd/devlog/20162601/poll.html (nonexistent)
@@ -1,24 +0,0 @@
-
-
-
1. How many of your boards REQUIRE burried or blind vias? [percentage]
-
2. How many of your boards could BENEFIT burried or blind vias? [percentage]
-
3. When your board REQUIRED them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no]
-
4. When your board could BENEFIT using them, do you more often find a workaround to stick with pcb instead of switching to another design tool? [yes/no]
-
5. Have you ever tried pcb-rnd? [yes/no]
-
6. Would you try pcb-rnd if it offered blind/burried vias? [yes/no]
-
7. Would you consider switching to pcb-rnd if it offered blind/burried vias? [yes/no]
-
8. Approximately how many boards have you done so far with pcb (pcb mainline/branches/forks included, using gschem/gnetlist not required)? "1 board done" means you had one or more physical copies of the board. [rough estimation, positive integer]
-
9. Approximately how many boards have you done with other packages? [rough estimation, positive integer]
-
10. What OS would you prefer to do your pcb layouts on (assuming your favorite layout tool is/would be available on it)? [one of: (GNU/)Linux, *BSD, OSX, windows, other; if you like more, select the one you would spend most time on!]
-
-
-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:
-
-
tries to do one thing - e.g. linked lists, without coupling it with a custom memory allocator
-
is simple - the API is so small that it's easy to learn it in minutes
-
is small - so that if anything breaks it's very easy to find and fix the bug (when did you last debug internals of glib?)
-
is replaceable - since they are independent, if one doesn't work up to expectations, it's real easy to replace it without affecting any other part; e.g. replacing linked lists without replacing hash tables
-
-
-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:
-
-
the GTK HID: because gtk is already coupled with glib, it doesn't make much sense to remove glib from the gtk HID code
-
the toporouter plugin: the code is huge and will be potentially deprecated anyway (lack of developer resources/user interest)
-
the puller: glib should be removed from the puller long term but the code is big and there's no much user need for it in pcb-rnd
-
-
-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-rnd/devlog/20151028_glib.html
===================================================================
--- trunk/doc-rnd/devlog/20151028_glib.html (revision 5606)
+++ trunk/doc-rnd/devlog/20151028_glib.html (nonexistent)
@@ -1,65 +0,0 @@
-
-
-
-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.
-
-
glib is not a lib that tries to solve something, it is a prorgamming
-environment that tries to supersede C.
-
-
As such, it feels free to mess with the environment, redefine C
-keywords as it sees fit, because once you use glib, why would you use
-anything else? And once you use glib, you are programming in glib, not in
-"plain C".
-
-
Grepping through the pcb-rnd code, I see that pcb-rnd does not try to
-use glib as a programming environment, but needs only 2 and a half
-features: hash, list and rarely dynamic strings. Any other glib call is
-just a must that had to be done that way to get hashes and lists working.
-
-
genht is 510 sloc. I have a generic list implementation (which, by the
-way, is more efficient than glib's) It costs 256 sloc. So having
-type-independent hashes and lists in C89 costs less than 800 lines of code
-if you pick the right libs. Glib's include/ alone is over 24000 sloc!
-And in return glib breaks inline...
-
-
-
-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-rnd/devlog/20160126.html
===================================================================
--- trunk/doc-rnd/devlog/20160126.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160126.html (nonexistent)
@@ -1,59 +0,0 @@
-
-
-
-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")
-
-
-
1. only half of the users would consider even trying pcb-rnd for blind/burried vias
-
2. there was only one user who'd consider switching to pcb-rnd for blind-burried vias - this feature doesn't seem to be valuable enough to attract users (details below)
-
3. about half of the users need blind/burried via; when they do, they don't use pcb
-
4. 9 out of 10 users runs PCB on Linux
-
-
-
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-rnd/devlog/20160802.html
===================================================================
--- trunk/doc-rnd/devlog/20160802.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160802.html (nonexistent)
@@ -1,25 +0,0 @@
-
-
-
-Reflecting to (but not joining) the annual geda-user language/libs debate,
-the policy of pcb-rnd (and later cschem) on this:
-
-
the core part of the code is in C - not in C++, C#, cobol, ada, haskell, etc.
-
external dependencies are minimized, especially core shouldn't depend on too many external libs and tools (e.g. core shouldn't depend on glib)
-
core doesn't know anything about [turing complete] scripting languages, user scripting is provided by a plugin
-
the scripting plugin does not attempt to restrict the user to My Favorite Language - it rather supports 10+ different languages, from ruby through awk through python to lua; it even supports an older version of guile; all languages are options.
-
-The above set of rules is crafted so that compiling core functionality is easy
-and excess external libs (gtk, glib) are needed only for optional features
-(such as the gtk hid in pcb-rnd). However, it's equally important not to
-restrict users in optional extras that may require more dependencies. This is
-solved by minimizing core and moving functionality behind APIs in a plugin
-system.
-
-This policy is very unlikely to change in the future - if you believe
-the core should be rewritten in your favorite language, please fork the
-project or start a new one.
-
Index: trunk/doc-rnd/devlog/20160409/pie_col_3.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_3.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_3.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_3.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_3.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160409/poll.csv
===================================================================
--- trunk/doc-rnd/devlog/20160409/poll.csv (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/poll.csv (nonexistent)
@@ -1,9 +0,0 @@
-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-rnd/devlog/20160409/pie_col_4.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_4.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_4.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_4.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_4.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160409/poll.tsv
===================================================================
--- trunk/doc-rnd/devlog/20160409/poll.tsv (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/poll.tsv (nonexistent)
@@ -1,9 +0,0 @@
-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-rnd/devlog/20160409/pie_col_5.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_5.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_5.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_5.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_5.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160409/header.csv
===================================================================
--- trunk/doc-rnd/devlog/20160409/header.csv (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/header.csv (nonexistent)
@@ -1 +0,0 @@
-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-rnd/devlog/20160409/pie_col_7.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_7.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_7.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_7.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_7.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160409/header
===================================================================
--- trunk/doc-rnd/devlog/20160409/header (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/header (nonexistent)
@@ -1,7 +0,0 @@
-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-rnd/devlog/20160409/poll.html
===================================================================
--- trunk/doc-rnd/devlog/20160409/poll.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/poll.html (nonexistent)
@@ -1,98 +0,0 @@
-
-
-
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.
-
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
-
-
-
-
-
-
-
-
-
-
-
-
-
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
-
-
Index: trunk/doc-rnd/devlog/20160409/legend.txt
===================================================================
--- trunk/doc-rnd/devlog/20160409/legend.txt (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/legend.txt (nonexistent)
@@ -1,60 +0,0 @@
-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-rnd/devlog/20160409/pie_col_1.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_1.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_1.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_1.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_1.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160409/pie_col_2.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/devlog/20160409/pie_col_2.png
===================================================================
--- trunk/doc-rnd/devlog/20160409/pie_col_2.png (revision 5606)
+++ trunk/doc-rnd/devlog/20160409/pie_col_2.png (nonexistent)
Property changes on: trunk/doc-rnd/devlog/20160409/pie_col_2.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/devlog/20160314_valgrind_flex.html
===================================================================
--- trunk/doc-rnd/devlog/20160314_valgrind_flex.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160314_valgrind_flex.html (nonexistent)
@@ -1,79 +0,0 @@
-
-
-
-
-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:
-
-
remove the header lines one by one and see if the leak is still there - won't work if a missing header changes how the whole code runs
-
change the size of each header, one by one, and see which action changes leak size - a lot of iterations, and valgrinding is slow
-
-
-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):
-
-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-rnd/devlog/20160716_sprint.html
===================================================================
--- trunk/doc-rnd/devlog/20160716_sprint.html (revision 5606)
+++ trunk/doc-rnd/devlog/20160716_sprint.html (nonexistent)
@@ -1,81 +0,0 @@
-
-
-
-
-Please start with procedure I and proceed to procedure II then to procedure III.
-You can postpone or stop any time, even partial results are useful.
-
-The most important procedures are I. and II., which together are estimated
-to take something between 40 and 90 minutes.
-
-No installation, no root privileges required. No interference expected with
-your pcb mainline installation. What you'll need is about the same you would
-need for compiling mainline or a random application:
-
-
an svn client (e.g. apt-get install subversion)
-
a C compiler (e.g. apt-get install gcc - anything that supports C99 should work)
-
the normal development libs (e.g. libc)
-
extra libs depending on your desired setup (e.g. libgtk2-0-dev)
-
make
-
-
-
I. Setup [10..30 minutes]
-
-
Objective: get a running pcb-rnd.
-
steps:
-
-
1. check out the code in a new directory: svn checkout svn://repo.hu/pcb-rnd/trunk
-
2. configure: cd trunk; ./configure
-
3. check the summary the last step produced; if you don't like it or anything is suspicious, consult Igor2 on IRC
-
4. compile: cd trunk; make
-
5. check if the compilation terminated with error (->Igor2 on IRC)
-
6. dry run: cd trunk/src; ./pcb-rnd
-
7. check if it generally runs as expected (note: there's no opengl, the menu layout and some default settings are slightly different)
-
8. please report even if everything worked: it's for the record/statistics; please include, in your report:
-
-
a. your system: uname -a
-
b. whether you used the gtk HID or the lesstif HID or both
-
-
-
-
-
II. Test drive [30..60 minutes]
-
-
-
Objective: find random bugs and make suggestions via a simulated production test drive.
-
steps:
-
-
1. take on of your existing .pcb (preferably one that you can share in case of a bugreport is needed)
-
2. copy the .pcb to trunk/src as foo.pcb
-
3. run cd trunk/src; ./pcb-rnd foo.pcb
-
4. pretend carrying out a real modification; e.g. replace one of the ICs with a footprint of the same pin count but different dimensions (e.g. so8 -> ssop8 or sot23->to220). Pretend you really want to do this modification and pretend that the board will go in production. Do your usual routine (e.g. check gerbers).
-
5. if you see anything strange, find bugs, have suggestions:
-
-
a. consult Igor2 on IRC
-
b. if there are files to be "attached" or your observation/question can only be stated in a medium sized novel, please send an email to pcb-rnd (at) igor2.repo.hu (and then we can still discuss it on IRC)
-
c. it is sometimes worth checking the behavior of a recent mainline pcb; there are bugs and oddities present in both current mainline and pcb-rnd (because of the common ancestor)
-
-
-
-
-
III. Systematic testing [60..90]
-
-
Objective: systematic testing of specific features that are affected
- by recent code rewrite/development.
-
steps:
-
-
1. contact Igor2 on IRC to get a chunk of the tests
-
2. understand the subsystem in question (from user perspective)
-
3. use your fantasy to invent test methods to see whether the
- subsystem works in common or normal use cases
-
4. use your fantasy to invent test methods to see whether the
- subsystem works in corner cases
-
5. report anything that seems like a bug or undesired behavior or regression
-
6. please do report if there's no bug and the given subsystem
- worked as expected; positive results are just as important as negative ones
-
-
-I received 9 partial 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")
-
-
-
1. very few users use the lesstif hid, still user count is more than 1
-
2. users are open to try alternative menu/hotkey layouts...
-
3. ... and only a few users change the default layout
-
4. ... because they are happy with the defaults and/or don't want to maintain the diffs on upgrades
-
5. there is a strong demand for multikey in the GTK HID
-
7. use of vendor (drill) mapping is rare
-
-
-
My conclusions
-pcb-rnd: the GTK HID needs multi-key support.
-
-Community: although users express their needs, they do not contribute
-even in smallish, non-programming tasks like designing the hotkey layout.
-This is probably in-line with the answers for 4: they don't really customize
-things, they want to use the software as is.
-
-Conclusion: it is worth shipping multiple menu/keyboard layouts as long as
-they are all maintained in the central repo (questions 2, 3 and 4). It is
-pointless to invest in tools that make customization easier or to prepare
-for collecting user-customized menu files, as users won't invest any time in
-this.
-
-
-
-
-
-
-
Index: trunk/doc-rnd/devlog/20161014_cleanup.html
===================================================================
--- trunk/doc-rnd/devlog/20161014_cleanup.html (revision 5606)
+++ trunk/doc-rnd/devlog/20161014_cleanup.html (nonexistent)
@@ -1,35 +0,0 @@
-
-
-This is a long term plan (these will happen slowly, step-by-step, gradually, in
-the background, in parallel with the normal schedule of development:
-
-
phase 0: port the rest [almost done]
-
-
import the remaining plugins and exporters before the big cleanup because it's cheaper to port them now
-
-
phase 1: reorg
-
-
reorganize the code: from action-oriented (e.g. change.c, remove.c, mirror.c) into object-type-oriented code (e.g. obj_line.c, obj_arc.c)
-
global*.h must be dissolved/removed
-
macro.h should be dissolved/removed
-
const.h should be reduced to 1/3
-
-
phase 2: clean the namespace
-
-
pcb_ prefixes
-
unify convention: underscores instead of CamelCase, prefer shorter names
-
better connection between file name and function name prefixes (don't invent 3 different names for the same thing)
-
-
phase 3: split & pack
-
-
move out generic, non-pcb-specific code to "external libs" (e.g. polygon, heap, the conf system)
-
determine layering of the new lib system (e.g. a generic unit, printf, etc. util lib on layer 0, then a lib about the basic object types on layer 1, then footprint libraries and other plugins on layer 2)
-
compile one .a file per layer, link the final executable using those .a files
-
make the libs installable, together with the headers
-
-
-The file a CAD program loads and saves is likely to end up in a Version
-Control System (VCS) sooner or later. To make VCS more meaningful, the
-changes to the file need to be minimal and relevant. For example in a
-load-save round trip (i.e. load the file in the CAD and save it in another
-file without any modification) the diff should be empty. If the user adds a new
-object, the diff should contain only lines added for the new object. (And maybe
-a few lines of changes in an index, if there's an index, but I believe it's
-better if there's no index.) Likewise, if an object is deleted, it is expected
-to result a few lines removed, preferably at a single location.
-
-
-Terminology used in this document:
-
-
file is the data file, represented in a structured text format;
- for the whole document except for the last chapter, any format may work:
- xml, json, ini, lihata, etc.
-
node a data node; may be:
-
-
a leaf node with payload: an actual data item (like a number)
-
a hash that contains an unordered set of other named nodes
-
a list is an ordered list of named or unnamed nodes
-
-
-
-The file is a tree; even an ini file is a tree with 1 or 2 levels (bottom
-level is a hash of text nodes, top level, groups, represent another hash). An
-xml is a list of lists with text nodes and non-text-node attributes
-representing a hash.
-
-
Problem #0: order
-To achieve the above goals, both gschem and pcb and pcb-rnd are prudent:
-objects are ordered in memory. This is necessary because in an unordered
-list or hash if the number of objects changes (objects added or removed)
-the saving order may shuffle, causing a lot of unnecessary changes.
-
-This problem is already solved.
-
-
Problem #1: canonical form
-Our file formats are plain text. While there are certain constructs that have
-strict format, e.g. a string in quotes can be described only one way without
-changing the content of the string, other parts have alternatives:
-
-
white spaces and other field separators
-
numerical formats: is 8 the same as 08 or 8.0?
-
pcb flag formats, old/new style: the same object can be described
- using different syntax constructions, sometimes resulting the same
- object
-
-
-This problem is seemingly solved by using a canonical form: even if the
-loader may accept alternatives, the save code always generates the same formatted
-output, down to the last whitespace indentation.
-
-
Problem #2: hand editing, external scripts
-However, the canonical format is not always the most convenient for the user.
-Sometimes different indentation, maybe even locally, may improve readability.
-Unfortunately a CAD round-trip brings back the file to canonical format, removing
-any user formatting. Or in other words, the user needs to learn the syntax
-of the file format and how the canonical format looks like, else user
-changes to a file may cause VCS noise later.
-
-Even worse, 3rd party scripts need to learn the canonical format too, for the
-same reason.
-
-
-
The solution
-One solution is to merge the canonical format and the syntax, so the resulting
-specification is so strict that there are no alternatives but everything can
-be written using only a single, well described format. This solves problem
-#1 and #2, but creates problem #3: a text file format as rigid as a binary
-format would be. While it could be still parsed by text tools easily, it
-would be much harder to emit properly using the same tools or even harder to
-edit manually, with a text editor. In this sense it may start losing its
-most important text-file-property: free form, to some extent.
-
-An alternative is that the CAD program doesn't save canonical format over
-an existing file but tries to accommodate to the format the file already features.
-This solves problem #0, #1, #2 and #3, allowing the user (or 3rd party scripts)
-to use whatever formatting they prefer, with clean round trips.
-
-
How to implement it (in theory)
-A few unusual features are required:
-
-
F1: the parser needs to be aware of otherwise unimportant
- characters (e.g. whitespace in indentation)
-
F2: if (payload) data is to be converted to a native format by
- the program, the original text representation needs to be saved;
- e.g. the input file contains 4.99999999, the program loads it to
- a float and later saved back, it may end up as 4.999997836;
- instead if the data did not change, the original text shall be
- saved back; this also solves the 005 vs 5 vs 5.0 problem
-
F3: new data should be inserted, obsolete data should be removed
- without reordering stationary data
-
-
-
The obvious approach
-An obvious approach would be to smarten the parser and store delimiters
-(e.g. whitespace) and the original text version for each data node, along with
-the order of nodes in the original file.
-
-
The less obvious approach
-A second approach is to ignore these details on load and keep on storing data
-in native binary format in memory. On save, start parsing the original file
-(or a snapshot of it taken load-time), and:
-
-
any non-data-payload character should be copied the the output;
- this includes whitespace, delimiters, comments, syntax sugar;
- this solves F1
-
if a node did not change, the parser copies it byte-to-byte to
- the output (solves F2 partially - no format change if data is
- unchanged in memory);
-
value change check: while parsing, convert the original value to
- native format again and compare, which solves F2: the same
- string->native conversion should yield the same native result;
- if our in-memory representation differs, it has changed and the
- new value should be copied to the output instead of the old value;
- the format of the new value doesn't matter, can be canonical, since
- the diff is already caused by the fact that the value has changed.
-
if the language supports ordered lists: before emitting list items,
- the input list must be read through (pre-read) and the in-memory and
- just-parse lists need to be compared to detect changes in order;
- existing list items are copied as described above; list items
- deleted in-memory are ignored; list items added in-memory are
- written out (solves F3)
-
if the language supports unordered hashes: check each key parsed;
- if it exists in-memory, copy/write it normally; if it doesn't,
- delete it; add new hash items (the ones present in-memory but
- not seen when the parser reaches the end of the hash; solves F3)
-
-
-This may sound more expensive than the first approach, because the parser needs
-to run again on save. However, the costs of the previous approach are
-high too:
-
-
essentially the whole file needs to be stored in-memory
- (for whitespace), but not in one bug chunk but in many
- little chunks among with the data nodes (which leads to
- allocation overhead); the original values need to be stored in
- text too, to solve the numeric problems
-
either the same string->native conversion needs to be done using
- stored text values; or the code needs to keep track of which node
- changed using some data-changed bit
-
the same list/hash merging needs to be done
-
-
-If the syntax-sugar overhead of the file format is low, majority of all
-bytes will be actual node data (need to be stored) and delimiters/indentation
-(need to be stored). Then it might be cheaper to store it all in one bug chunk
-and re-parse it (without building a DOM) than storing the same data in small
-chunks.
-
-
-
An even less obvious approach
-Take the previous method, but assume the application does not change the
-order of objects on ordered lists and each object has some sort of unique
-identifier (so two identical looking objects can't be on a list).
-This makes list merging much simpler and doable in a single pass, keeping
-a list item pointer with the in-memory list:
-
-
initialization: set the pointer to the first element of the list
-
iteration: parse the first (next) item of the list
-
check if it exists in-memory and is the first
-
-
if yes, copy from the original file, increase the pointer by
- one element
-
if not, check if it got deleted (not present on the list
- in-memory) and skip it if so; pointer stays in place
-
if not, check if it is on the in-memory list as a later entry;
- if so, insert all preceding entries from the in-memory list,
- increasing the pointer by one for each element written
-
-
repeat the iteration until there are no more items on the input list
-
check if there are items remaining from the pointer, if so output
- them (they will end up at the end of the list in the output file)
-
finished: the output file's list now matches the in-memory list.
-
-
-Empty lists may need special (but trivial) treatment.
-
-While copying an existing node, it is possible to "pick up" style
-e.g. indentation. When a new item needs to be added, such picked up local
-style info can be used to generate output that looks similar to other items
-in its local environment. For example the first time a list or hash item
-needs to be added is right after at least one item of the given hash or
-list is already parsed, which means the style of an item is already know.
-
-
How it is implemented in practice
-Using the last approach from the above list, with an utility library for
-lihata. The full list of requirements (on the application and the tree
-structure):
-
-
the root element of the input file and the in-memory representation
- must fully match
-
list items must have names that are unique to the list, even across
- item removal from the list within a session (so a newly added item
- never has the same name as a past item parsed back from the file)
-
the application must not change the order of elements on a list -
- new elements may be inserted anywhere and old elements may be
- removed from anywhere but the order of any two remaining old
- elements must be preserved
-
-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:
-
import, test, extend the glue layer; scripts can:
-
-
register new actions
-
create new menus and submenus
-
execute existing actions
-
pop up simple dialog boxes (message, report, progress bar, file selection) -- check out the video
-
build and pop up custom dialog boxes (so called attribute dialogs)
-
search for objects (lines, arc, polys, vias, etc.) on the layout
-
create new objects on the layout
-
change "page" properties (dimensions of the board)
-
debug draw on the gui (slightly broken on gtk due to some gtk hid bugs)
-
-
-
-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-rnd/devlog/20150731b_gtk.html
===================================================================
--- trunk/doc-rnd/devlog/20150731b_gtk.html (revision 5606)
+++ trunk/doc-rnd/devlog/20150731b_gtk.html (nonexistent)
@@ -1,36 +0,0 @@
-
-
-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:
-
-
I am really adding the new widgets...
-
... under the right parent
-
... with the right properties
-
-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-rnd/devlog/poll_common/genpie.sh
===================================================================
--- trunk/doc-rnd/devlog/poll_common/genpie.sh (revision 5606)
+++ trunk/doc-rnd/devlog/poll_common/genpie.sh (nonexistent)
@@ -1,38 +0,0 @@
-#!/bin/sh
-
-gen()
-{
- awk -F "[\t]" -v "col=$1" '
- BEGIN {
- if (col < 0) {
- col = -col
- keep_na = 1
- }
- }
- {
- val=$col
- if (val == "-") {
- if (keep_na)
- val="n/a"
- else
- next
- }
- split(val, VAL, "[+]")
- for(n in VAL) {
- VOTE[VAL[n]]++
- }
- }
-
- END {
- for(n in VOTE) {
- print "@slice\n" VOTE[n]
- print "@label\n" n
- }
- }
- '
-}
-
-for n in $*
-do
- (gen $n < poll.tsv | animpie && echo "screenshot \"pie_col_$n.png\"") | animator -H -x 150 -y 150
-done
Property changes on: trunk/doc-rnd/devlog/poll_common/genpie.sh
___________________________________________________________________
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property
Index: trunk/doc-rnd/devlog/poll_common/genhtml.sh
===================================================================
--- trunk/doc-rnd/devlog/poll_common/genhtml.sh (revision 5606)
+++ trunk/doc-rnd/devlog/poll_common/genhtml.sh (nonexistent)
@@ -1,54 +0,0 @@
-#!/bin/sh
-(
-echo '
'
-echo "
"
-sed "s@^@
@" < header
-sed "s@^@
@;s@\t@
@g" < poll.tsv
-echo "
"
-hl=`wc -l < header`
-for n in `seq $hl`
-do
- ./genpie.sh $n
- fn=pie_col_$n.png
- if test -f "$fn"
- then
- echo "
-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-rnd/devlog/20150830a_fork_faq.html
===================================================================
--- trunk/doc-rnd/devlog/20150830a_fork_faq.html (revision 5606)
+++ trunk/doc-rnd/devlog/20150830a_fork_faq.html (nonexistent)
@@ -1,257 +0,0 @@
-
-
-
-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.
-
-
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-In version 1.0.8 and 1.0.9 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.0.9
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-In version 1.0.8 and 1.0.9 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.0.9
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-
module
size [sloc]
status
configure default
description
-
-
-
autoplace
612
-
works
-
buildin
-
Automatically place elements.
-
autoroute
4337
-
works
-
buildin
-
Automatically route selected or all rats. This is the original autorouter.
-
dbus
438
-
disabled
- (TODO: needs scconfig support)
-
disabled
-
Remote control PCB using DBUS.
-
djopt
2320
-
works
-
buildin
-
Various board optimization algorithms.
-
export_bom
374
-
works
-
buildin
-
Export bom (Bill of Materials)
-
export_gcode
2452
-
works
-
buildin
-
Export to gcode
-
export_gerber
972
-
works
-
buildin
-
Export to gerber
-
export_lpr
96
-
works
-
buildin
-
Export to lpr (using export_ps to generate postscript)
-
export_nelma
685
-
works
-
buildin
-
Export to nelma (Numerical capacitance calculator)
-
export_png
1107
-
works
-
buildin
-
Export to png, gif and jpeg
-
export_ps
1613
-
works
-
buildin
-
Export postscript or embedded postscript.
-
fontmode
163
-
works
-
buildin
-
Font editing actions.
-
gpmi
3003
-
works
-
buildin
- (if gpmi is installed)
-
Scriptable plugin system with about 10 scripting languages supported and dynamic load/unload of scripts that can manipulate the GUI, the board, can implement exporters, etc.
-
import_edif
3578
-
works
-
buildin
-
Import code for netlists in the EDIF format.
-
import_sch
259
-
works
-
buildin
-
Imports element and netlist data from the schematics (or some other source).
-
legacy_func
72
-
works
-
buildin
-
Random collection of old/obsolete (legacy) functions. 3rd party plugins may depend on them. This module implements C functions and variables and does not register actions or flags.
-
mincut
886
-
works
-
buildin
-
Use the minimal cut algorithm to indicate shorts: instead of highlighting two random pins/pads, try to highlight the least number of objects that connect the two networks.
-
oldactions
57
-
works
-
disabled
-
Random collection of old/obsolete actions. Bell(): audible feedback; DumpLibrary(): print footprint library on stdout
-
puller
1884
-
works
-
buildin
-
Pull traces to minimize their length.
-
renumber
222
-
works
-
buildin
-
Renumber elements (renaming them) and generate a text file for back annotation.
-
stroke
124
-
partially works (doesn't work with lesstif; works with the gtk hid, but there's no zoom bindings)
-
disabled
- (requires libstroke installed)
-
Gesture recognition with libstroke.
-
toporouter
6165
-
fails
- (infinite loop in gts)
-
disabled
-
Automatically route selected or all rats using a topological algorithm. This is the new autorouter from 2009.
-
vendordrill
572
-
works
-
buildin
-
Vendor drill mapping.
-
-
-
Index: trunk/doc-rnd/wishlist.txt
===================================================================
--- trunk/doc-rnd/wishlist.txt (revision 5606)
+++ trunk/doc-rnd/wishlist.txt (nonexistent)
@@ -1,34 +0,0 @@
-Active user wishes:
- W1: cschem [Chris]
- W2: (BLOCKED: lihata testing) proper primitives [Chris]
- W3: (BLOCKED: lihata testing) more generic footprints [Chris, Evan]
- W4: user doc [Miloh]
- W5: (BLOCKED: lihata testing) 3d modeller export [Miloh, Evan]
- W7: (BLOCKED: lihata testing) programmable drc (star grounding) [James]
- W8: (BLOCKED: need resources) gl support [Erich, Evan]
- W9: push & shove [Erich, Evan]
-
-User wishes fulfilled:
- W6: GUI access to object attributes: gtk editor, find/select by attrib [James]
-
-Plan (parallel threads of development):
-
- A. file format and model
- Steps:
- 1. (done) lihata persistency
- 2. (done) native lihata file format
- 3. (done) extend the file format
- - everything should have an attribute hash -> W6
- - footprints should have optional attachments (e.g. 3d models) -> W5
- This helps us testing out the persistent-lihata idea that'd be
- later used in chscem from the start -> W1
- This is also needed for more generic footprint implementation -> W3
-
- B. visible attribute support
- Steps:
- 1. (done) GTK dialog box for attribute edition
- 2. (done) search & select should work by attribute
- 3. (done) extend the routing style system to auto-add attributes
- (this needs A., the new file format)
- Allows the user to manage properties like "50 ohm net" in attributes,
- to group objects by property, and to select them by property. -> W6
Index: trunk/doc-rnd/mods3/gen.sh
===================================================================
--- trunk/doc-rnd/mods3/gen.sh (revision 5606)
+++ trunk/doc-rnd/mods3/gen.sh (nonexistent)
@@ -1,152 +0,0 @@
-#!/bin/sh
-
-path=../../src_plugins
-
-sloc()
-{
- (cd "$1" && sloccount .) | awk '/^Total Phys/ { size=$9; sub(",", "", size); print size }'
-}
-
-gen_pie()
-{
- local bn=$1 code_size=$2 color=$3
- echo ""
- echo "@slice"
- echo "$code_size"
- echo "@label"
- echo "$bn ($code_size)"
- if test ! -z "$color"
- then
- echo "@color"
- echo "$color"
- fi
-}
-
-rm -f *.pie *.lines
-
-echo "#autogenerated by gen.sh" > mods.pie
-echo "#autogenerated by gen.sh" > after.pie
-
-echo Core >&2
-tmp=/tmp/pcb-mods-stat
-mkdir $tmp
-cp -r ../../src/*.c ../../src/*.h ../../src/Makefile* $tmp
-code_size=`sloc $tmp`
-gen_pie "core" $code_size "#00ff88" >> after.pie
-
-#echo 3rd >&2
-#code_size=`sloc ../../src_3rd`
-#gen_pie "3rd" $code_size >> after.pie
-
-echo "" > classes
-
-(
-cat pre.html
-for n in $path/*
-do
- if test -d "$n"
- then
- echo $n >&2
- bn=`basename $n`
- code_size=`sloc $n`
- total=$(($total + $code_size))
- class=`sed '
- /^#implements:/ {
- s/#implements: *//
- s/[()]//g
- p
- }
- { d }
- ' < $n/README`
- echo "$class" >> classes
-
- echo "$code_size" >> $class.lines
- gen_pie $bn $code_size >> $class.pie
-
-# case $bn in
-# gpmi) echo "@pull" >> mods.pie; echo "0.1" >> mods.pie;;
-# esac
-
- echo "
" desc
- }
- ' < $n/README
- fi
-done
-cat post.html
-gen_pie "plugins" "$total" "#0088ff" >> after.pie
-) > index.html
-
-for n in *.lines
-do
- lines=`awk '{ sum += $1 } END { print sum }' < $n`
- bn=${n%%.lines}
- gen_pie $bn $lines >> mods.pie
-done
-
-
-classes=`sort < classes | uniq`
-
-for n in $classes after mods
-do
- animpie < $n.pie | animator -H -d $n
- pngtopnm ${n}0000.png | pnmcrop | pnmtopng > $n.png
- rm ${n}0000.png
-done
-
-
-rm classes
Property changes on: trunk/doc-rnd/mods3/gen.sh
___________________________________________________________________
Deleted: svn:executable
## -1 +0,0 ##
-*
\ No newline at end of property
Index: trunk/doc-rnd/mods3/export.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/export.png
===================================================================
--- trunk/doc-rnd/mods3/export.png (revision 5606)
+++ trunk/doc-rnd/mods3/export.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/export.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/after.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/after.png
===================================================================
--- trunk/doc-rnd/mods3/after.png (revision 5606)
+++ trunk/doc-rnd/mods3/after.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/after.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/before.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/before.png
===================================================================
--- trunk/doc-rnd/mods3/before.png (revision 5606)
+++ trunk/doc-rnd/mods3/before.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/before.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/mods.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/mods.png
===================================================================
--- trunk/doc-rnd/mods3/mods.png (revision 5606)
+++ trunk/doc-rnd/mods3/mods.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/mods.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/hid.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/hid.png
===================================================================
--- trunk/doc-rnd/mods3/hid.png (revision 5606)
+++ trunk/doc-rnd/mods3/hid.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/hid.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/fp.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/fp.png
===================================================================
--- trunk/doc-rnd/mods3/fp.png (revision 5606)
+++ trunk/doc-rnd/mods3/fp.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/fp.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/post.html
===================================================================
--- trunk/doc-rnd/mods3/post.html (revision 5606)
+++ trunk/doc-rnd/mods3/post.html (nonexistent)
@@ -1,17 +0,0 @@
-
-
-
Classes
-Each plugin implements a class (rarely a set of classes). Classes are:
-
-
name
description
-
(feature)
random features directly accessible for the user, usually actions
-
(lib)
support code library for other plugins (core doesn't depend on these); functionality not directly accessible for the user but other plugins may depend on it
-
hid
Human Interface Device: interactive user interface, usually GUI
-
import
load alien formats into the design space
-
export
save (parts of) the design space in alien formats
-
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-In version 1.0.8 to 1.1.0 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.1.3
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-
-
total size per class
-
IO plugins
-
-
-
-
-
-
feature plugins
-
export plugins
-
-
-
-
-
HID plugins
-
import plugins
-
-
-
-
-
library plugins
-
footprint plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-
module
size [sloc]
status
configure default
class
description
-
-
Index: trunk/doc-rnd/mods3/lib.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/lib.png
===================================================================
--- trunk/doc-rnd/mods3/lib.png (revision 5606)
+++ trunk/doc-rnd/mods3/lib.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/lib.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/index.html
===================================================================
--- trunk/doc-rnd/mods3/index.html (revision 5606)
+++ trunk/doc-rnd/mods3/index.html (nonexistent)
@@ -1,428 +0,0 @@
-
-
-
pcb-rnd modularization
-
Why bother...
-I believe good software should be modular. This is especially important in
-the context of large software, such as CAD applications. There should be
-a thin core that can model the world and provide the basic operations defined
-on it but anything else should go in separate modules.
-
-Fortunately PCB already had a strong infrastructure supporting this idea.
-It has dynamic loadable plugins and the GUI and exporters are in separate
-HID modules. While working on pcb-gpmi and later pcb-rnd, I added the
-gpmi module as a separate plugin.
-
-In version 1.0.8 to 1.1.0 a cosiderable chunk of core code has been moved into
-core plugins. A core plugin is just a plugin that is
-maintained together with the core, in the same repository, still the code is
-somewhat detached from the core. More importantly, the user can choose, for
-each plugin, separately:
-
-
to compile it as a buildin (static-link it into the pcb executable)
-
to compile it as a plugin (dynamic-link it runtime, if the .so is installed in the plugins/ directory)
-
to disable the plugin, so it is not compiled at all
-
-
-I believe such modularization has benefits on multiple levels:
-
-
it is possible to compiler smaller, potentially faster executables by omitting features the specific user would never use anyway
-
in a distribution dynamic-link plugins can be distributed as separate packages providing the user with the option to decide what features to install
-
such plugins have to have some sort of APIs if they want to reference eachother or if the code needs to reference them; such an API may not (and often did not) exist when the code is part of the core
-
-
-
Progress in charts
-
Before-after
-All numbers are in SLOC
-and are acquired running sloccount on the given directory. While lines of
-code alone is not a true measure of complexity, it's a good estimation. The
-slices of pie charts are the major components of the pcb-rnd executable.
-
-
-
-
Before modularization: pcb-rnd version 1.0.7
- Note: gpmi was already a plugin
-
-
After modularization: pcb-rnd version 1.1.3
- Note: gpmi is part of the "plugins" slice
-
-
-
Zooming on to the plugins
-
-
-
-
-
total size per class
-
IO plugins
-
-
-
-
-
-
feature plugins
-
export plugins
-
-
-
-
-
HID plugins
-
import plugins
-
-
-
-
-
library plugins
-
footprint plugins
-
-
-
-(Red means the plugin doesn't really work).
-
-
Progress in numbers
-Below is a table with the summary of core plugins.
-
-
module
size [sloc]
status
configure default
class
description
-
-
-
autocrop
157
-
works
-
buildin
-
(feature)
-
Reduce the board dimensions to just enclose the elements.
-
autoplace
617
-
works
-
buildin
-
(feature)
-
Automatically place elements.
-
autoroute
4341
-
works
-
buildin
-
(feature)
-
Automatically route selected or all rats. This is the original autorouter.
-
boardflip
132
-
WIP
- (doesn't update rtrees)
-
disabled
-
(feature)
-
All objects on the board are up-down flipped.
-
dbus
486
-
WIP
- (needs to install the xml?)
-
disabled
-
(feature)
-
Remote control PCB using DBUS.
-
diag
167
-
works
-
disabled
-
(feature)
-
Actions for pcb-rnd core diagnostics, intended for developers. These are not in core because end users normally don't need these. As a plugin, due to dynamic loading, it can be dropped on an existing pcb-rnd installation with minimal risk of scaring away a reproducible bug.
-
distalign
426
-
works
-
buildin
-
(feature)
-
Introducing Align() and Distribute(), which work much like the similarly named functions in Visio. Given that PCB does not have the concept of "first selected object" to draw on, the reference points can be selected by arguments.
-
distaligntext
465
-
works
-
buildin
-
(feature)
-
Same as distalign, operates on text objects.
-
djopt
2320
-
works
-
buildin
-
(feature)
-
Various board optimization algorithms.
-
draw_fab
257
-
works
-
buildin
-
(feature)
-
Draw the fab layer (for various exporters).
-
export_bboard
419
-
WIP
-
disabled
-
export
-
Export breadboard
-
export_bom
230
-
works
-
buildin
-
export
-
Export bom (Bill of Materials)
-
export_dsn
447
-
Work-in-progress
-
disable
-
export
-
Export specctra .dsn files
-
export_dxf
3999
-
WIP
-
disabled
-
export
-
Export dxf
-
export_gcode
2468
-
works
-
buildin
-
export
-
Export to gcode
-
export_gerber
989
-
works
-
buildin
-
export
-
Export to gerber
-
export_ipcd356
467
-
Work-in-progress
-
disable
-
export
-
IPC-D-356 Netlist export.
-
export_lpr
104
-
works
-
buildin
-
export
-
Export to lpr (using export_ps to generate postscript)
-
export_nelma
678
-
works
-
buildin
-
export
-
Export to nelma (Numerical capacitance calculator)
-
export_openscad
1379
-
WIP
-
disabled
-
export
-
Export openscad
-
export_png
1119
-
works
-
buildin
-
export
-
Export to png, gif and jpeg
-
export_ps
1638
-
works
-
buildin
-
export
-
Export postscript or embedded postscript.
-
export_stat
258
-
works
-
buildin
-
export
-
Export various board statistics in lihata format
-
export_svg
566
-
works
-
buildin
-
export
-
Scalable Vector Graphics (SVG) exporter
-
export_test
257
-
disabled
- (work in progress)
-
buildin
-
export
-
A thin layer of code to dump exporter calls for testing the HID exporter API.
-
export_xy
272
-
works
-
buildin
-
export
-
Export XY centroid element data for pick & place.
-
fontmode
165
-
works
-
buildin
-
(feature)
-
Font editing actions.
-
fp_fs
380
-
works
-
buildin
-
fp
-
Footprint: file system based implementation. Used to be called Newlib: load footprints from directories. Run external processes for the parametric footprints.
-
fp_wget
303
-
works
-
buildin
-
fp
-
Footprint: get static (file) footprints from the web, e.g. from http://gedasymbols.org
-
gl
588
-
disabled
- (pcb-rnd has no support for opengl.)
-
disabled
-
(feature)
-
Common gl functions for hids.
-
gpmi
3056
-
works
-
buildin
- (if gpmi is installed)
-
(feature)
-
Scriptable plugin system with about 10 scripting languages supported and dynamic load/unload of scripts that can manipulate the GUI, the board, can implement exporters, etc.
-
hid_batch
317
-
works
-
buildin
-
hid
-
HID without GUI; read actions from stdin.
-
hid_gtk
16254
-
works
-
buildin
-
hid
-
GUI: the GTK HID.
-
hid_lesstif
6917
-
works
-
buildin
-
hid
-
GUI: the lesstif HID.
-
hid_remote
1116
-
WIP
-
disable
-
hid
-
Remote access HID: implement a protocol and use it to relay between a core and a remote HID implementation.
-
import_dsn
115
-
Work-in-progress
-
disable
-
import
-
Import specctra .dsn files
-
import_edif
3624
-
works
-
buildin
-
import
-
Import plugin for netlists in the EDIF format.
-
import_hyp
1547
-
WIP
-
disable
-
import
-
Import plugin for hyperlynx geometry.
-
import_netlist
136
-
works
-
buildin
-
import
-
Import plugin for netlists in the classic pcb netlist format.
-
import_sch
302
-
works
-
buildin
-
import
-
Imports element and netlist data from the schematics (or some other source).
-
io_kicad
2971
-
works
-
buildin
-
io
-
Load and save the design and elements in Kicad's s-expression format - this is the new, currently preferred format in Kicad.
-
io_kicad_legacy
944
-
works
-
buildin
-
io
-
Export the design and elements in Kicad's legacy format.
-
io_lihata
1935
-
works
-
buildin
-
io
-
Load and save the design and elements in the lihata board format.
-
io_pcb
2172
-
works
-
buildin
-
io
-
Load and save the design and elements in the original pcb text format.
-
jostle
445
-
works
-
buildin
-
(feature)
-
Pushes lines out of the way.
-
lib_gensexpr
6
-
works
-
disabled
-
(lib)
-
S-expression parser lib
-
lib_legacy_func
63
-
works
-
buildin
-
(lib)
-
Random collection of old/obsolete (legacy) functions. 3rd party plugins may depend on them. This module implements C functions and variables and does not register actions or flags.
-
loghid
272
-
WIP
-
disabled
-
(feature)
-
Sits between a HID (or exporter) and the core and logs all core->plugin calls made through the HID structure.
-
mincut
904
-
works
-
buildin
-
(feature)
-
Use the minimal cut algorithm to indicate shorts: instead of highlighting two random pins/pads, try to highlight the least number of objects that connect the two networks.
-
oldactions
154
-
works
-
disabled
-
(feature)
-
Random collection of old/obsolete actions. Bell(): audible feedback; DumpLibrary(): print footprint library on stdout; a set of debug actions useful for writing pcb scripts: Debug(), DebugXY(), Return(). Old plugin actions to toggle or set settings that are now accessible via the unified config system (vendordrill, djopt)
-
polycombine
207
-
works
-
buildin
-
(feature)
-
The selected polygons are combined together according to the ordering of their points.
-
polystitch
184
-
segfaults
-
disable
-
(feature)
-
The polygon under the cursor (based on closest-corner) is stitched together with the polygon surrounding it on the same layer. Use with pstoedit conversions where there's a "hole" in the shape - select the hole.
-
propedit
772
-
works
-
buildin
-
(feature)
-
List and edit properties of a group of objects.
-
puller
1887
-
works
-
buildin
-
(feature)
-
Pull traces to minimize their length.
-
query
1834
-
works
-
buildin
-
(feature)
-
pcb-rnd query language: execute expressions on objects and rules for the programmed drc.
-
renumber
308
-
works
-
buildin
-
(feature)
-
Renumber elements (renaming them) and generate a text file for back annotation.
-
report
1019
-
works
-
buildin
-
(feature)
-
Report() and ReportObject() actions - print a report about design objects.
-
rubberband_orig
599
-
works
-
buildin
-
(feature)
-
The original rubberband code.
-
shand_cmd
211
-
works
-
buildin
-
(feature)
-
vi-like command shorthands (1..3 character long commands)
-
smartdisperse
172
-
works
-
buildin
-
(feature)
-
Improve the initial dispersion of elements by choosing an order based on the netlist, rather than the arbitrary element order. This isn't the same as a global autoplace, it's more of a linear autoplace. It might make some useful local groupings. For example, you should not have to chase all over the board to find the resistor that goes with a given LED.
-
stroke
135
-
partially works (doesn't work with lesstif; works with the gtk hid, but there's no zoom bindings)
-
disabled
-
(feature)
-
Gesture recognition with libstroke.
-
teardrops
226
-
works
-
buildin
-
(feature)
-
Draw teardrops on pins.
-
toporouter
6161
-
fails
- (infinite loop in gts)
-
disabled
-
(feature)
-
Automatically route selected or all rats using a topological algorithm. This is the new autorouter from 2009.
-
vendordrill
516
-
works
-
buildin
-
(feature)
-
Vendor drill mapping.
-
-
-
Classes
-Each plugin implements a class (rarely a set of classes). Classes are:
-
-
name
description
-
(feature)
random features directly accessible for the user, usually actions
-
(lib)
support code library for other plugins (core doesn't depend on these); functionality not directly accessible for the user but other plugins may depend on it
-
hid
Human Interface Device: interactive user interface, usually GUI
-
import
load alien formats into the design space
-
export
save (parts of) the design space in alien formats
-
fp
footprint (element) library implementation
-
io
native file format (save & load) implementation
-
-
-
-
Index: trunk/doc-rnd/mods3/io.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/io.png
===================================================================
--- trunk/doc-rnd/mods3/io.png (revision 5606)
+++ trunk/doc-rnd/mods3/io.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/io.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/import.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/import.png
===================================================================
--- trunk/doc-rnd/mods3/import.png (revision 5606)
+++ trunk/doc-rnd/mods3/import.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/import.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods3/feature.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/mods3/feature.png
===================================================================
--- trunk/doc-rnd/mods3/feature.png (revision 5606)
+++ trunk/doc-rnd/mods3/feature.png (nonexistent)
Property changes on: trunk/doc-rnd/mods3/feature.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/misc/install_cgi.html
===================================================================
--- trunk/doc-rnd/misc/install_cgi.html (revision 5606)
+++ trunk/doc-rnd/misc/install_cgi.html (nonexistent)
@@ -1,45 +0,0 @@
-
-
-
Installation of the footprint CGIs
-
system requirements, 3rd party software
- The following software needs to be installed on the system
- that will host the scripts:
-
-
/bin/bash (did not test with POSIX shell)
-
awk (tested with gawk, may work with other modern implementation)
-
common binutils, e.g. ls, find
-
animator, the svn HEAD version; NOTE: it is possible to manually compile animator into a static executable (useful on dedicated web servers)
-
a web server that can execute plain old CGI scripts
-
a full checkout of pcb-rnd/trunk from svn://repo.hu/pcb-rnd/trunk
-
-
-
Installation
-Since the CGIs are just demo scripts for repo.hu and are not really installed
-anywhere else normally, there is no install script but a manual installation
-process. For both the parametric and the static footprint CGI:
-
-
check out pcb-rnd/trunk in a directory readable (but not writable) by www-data (or whatever user the CGI will run with)
-
copy the config file pcblib.cgi.conf from pcb-rnd/trunk/util to /etc
-
edit the config file; ignore setting sdir for now
-
hardlink, copy, or wrap the cgi files from under pcb-rnd/trunk/util into the web server's CGI directory
-
-
-For the static footprint CGI (set up the map cache):
-
-
cd to trunk/util/pcblib-map in the checkout and run make - NOTE: some awk scripts have hardwired CGI paths yet (TODO)
-
copy this directory to a web-accessible directory
-
set sdir to the absolute path of the web-accessible copy in /etc/pcblib.cgi.conf
-
-
-
Tips and tricks
-
cgi wrapping
-Making the checkout directly into the cgi-bin dir is not a good idea. Using
-a hard link on each CGI between the checkout and the cgi-bin dir is better,
-but an svn up will silently break the link leaving the old version live.
-The most stable solution is placing a wrapper script in the cgi-bin dir:
-
-
-
Index: trunk/doc-rnd/screenshot.jpg
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/screenshot.jpg
===================================================================
--- trunk/doc-rnd/screenshot.jpg (revision 5606)
+++ trunk/doc-rnd/screenshot.jpg (nonexistent)
Property changes on: trunk/doc-rnd/screenshot.jpg
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi_temp_inst.txt
===================================================================
--- trunk/doc-rnd/gpmi_temp_inst.txt (revision 5606)
+++ trunk/doc-rnd/gpmi_temp_inst.txt (nonexistent)
@@ -1,65 +0,0 @@
-GPMI system-wide installation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The installation process is somewhat manual at this early stage. Please
-follow the steps below.
-
-First, you'll need libgpmi - it's a general purpose script glue interface.
-
-A/1. svn checkout svn://repo.hu/gpmi/trunk gpmi/trunk
-A/2. look at doc/languages.txt there; if you have preferred languages,
-please install the -dev packages of those. My favorite is mawk, but I
-think most of the example pcb scripts would be in lua. Versions should
-match; it may be that gpmi works with a newer minor version out of the
-box, tho.
-A/3. run ./configure
-A/4. check if it found the language(s) you wanted; if not, or anything
-else breaks, please send me your scconfig/config.log
-A/5. make
-A/6. make install (as root, but see below)
-
-There are options to step 6:
-
-- if you want to check what it'd do, you could run this:
-
- install_root=/tmp/foo make install
-
- it's like DESTDIR for autotools: it will do everything but will use
- /tmp/foo instead of / so you see what it'd do without using root or
- messing with /usr
-
-- you can use make linstall instead of make install; this creates symlinks
-(pointing to the binaries in your user checkout) instead of copying the
-files. If gpmi changes and you need to update and recompile, you won't
-need to reinstall (until the number of files change).
-
-- there's a make uninstall, but it's more or less untested (failed once
-and worked once for me)
-
-Second, you'll need pcb-rnd:
-
-B/1. svn checkout svn://repo.hu/pcb-rnd/trunk pcb-rnd/trunk
-B/2. ./configure
-B/3. check the output; if anything went wrong, please send me
-scconfig/config.log
-B/4. make
-B/5. you don't need to install it for testing: cd src; ./pcb-rnd
-
-
-There are options in step 2: by default, if gpmi is found, it's compiled
-in "buildin" mode, which means script support is compiled into the pcb-rnd
-executable. An alternative is to have it as a plugin (dynamic linkable
-object). This can be done using the --plugin-gpmi argument for ./configure.
-
-
-GPMI local installation
-~~~~~~~~~~~~~~~~~~~~~~~
-GPMI can be installed without root, into a local user directory (typically
-under home). To achieve this, follow the above steps with the following
-modifications (assuming you want to install gpmi in ~/usr):
-
-A/3. ./configure --prefix=~/usr
-B/2. ./configure --gpmi-prefix=~/usr
-
-NOTE: you don't need to use install_root; gpmi will install under ~/usr as
-if it was /usr.
Index: trunk/doc-rnd/gpmi/scripting_intro.html
===================================================================
--- trunk/doc-rnd/gpmi/scripting_intro.html (revision 5606)
+++ trunk/doc-rnd/gpmi/scripting_intro.html (nonexistent)
@@ -1,226 +0,0 @@
-
-
-
Scripting intro
-This document is an introduction to GPMI for pcb-rnd users. It focuses on
-scripting pcb-rnd and doesn't discusses GPMI deeper than the minimum necessary.
-GPMI is more generic than shown here.
-
-The scope of the document is to describe the relations between pcb-rnd,
-hids, GPMI, glue packages and scripts. Details on how specific glue
-packages access pcb-rnd internals (or how those internals work) are
-described in other documents.
-
-
1. pcb-rnd internals
-
-Since scripts are glued to pcb-rnd internals, scripters need to know
-the basic concepts of how pcb-rnd is structured.
-
-
1.1 pcb-rnd, HIDs, plugins and GPMI
-pcb-rnd consists of:
-
-
a core that handles the file format, data structures, UI and exporter logics
-
a hid system that is a layer between core and the HIDs
-
a set of GUI HIDs which are responsible for interactive graphical display of the current design
-
a set of exporter HIDs which are responsible for exporting offline representation of the current design
-
a plugin system that can load HIDs from on the fly, from dynamic loadable libraries (.so or .dll)
-
a buildin system which is the "static link" variant of the plugin system: some plugins can be selected to be statically linked into the pcb-rnd executable so they are "always loaded"
-
-
-Note 1: at the moment GUI hids can not be plugins or buildins.
-
-Note 2: plugins/buildins are always exporter HIDs technically, but in practice
-they do not have to offer exporting. This means such a HID plugin is loaded
-and registered as an exporter on paper, but it doesn't really create a
-new export facility, just sits there, interacting with pcb-rnd (creating
-menus, actions, etc). Most script plugins do this.
-
-When pcb-rnd executable is compiled, the core, the default GUI and exporter HIDs
-and buildins are compiled into the executable. Later on
-
-The GPMI hid is an optional plugin that, by compile-time choice
-of the user, can be:
-
-
left out all-together - pcb-rnd does not have scripting
-
compiled as a plugin - when the .so (or .dll) is put in the right directory, pcb-rnd loads it during startup and has scripting
-
compiled as buildin - becomes part of the pcb-rnd executable so that scripting is always available
-
-
-
1.2. Actions, menus, exporters
-The core implements actions. An action is a command with custom arguments,
-e.g. Delete(Selected). These actions are the commands on the default command
-line in pcb-rnd. In batch mode the command language uses these actions as well.
-Remote controlling pcb-rnd using the --listen switch will read these actions
-on the standard input.
-
-GUI menus are configured to execute actions too. This also means it is impossible
-to realize an user-accessible functionality that can be triggered from
-the GUI command line, menu or batch input without making it an action.
-
-The only exception, where new functionality is not behind a new action is
-exporters. An exporter is a structured dialog box of options and a set of
-callback functions implementing a drawing API. Exporting works by the following
-steps:
-
-
An exporter HID may register one or more exporters.
-
When the user tries to export the design, pcb-rnd lists all
- registered exporters.
-
The user chooses one, and the preconfigured dialog box
- with the selected exporter's options are popped up.
-
pcb-rnd core runs the dialog and saves the results if the user
- clicked on the ok button.
-
pcb-rnd starts the exporting process: it calls the callbacks
- to draw the design layer by layer, object by object.
-
-
-
1.3. How a script can interact with the user
-
-
The script may register actions - these actions are instantly accessible from the GUI command line, on stdin with --listen and in batch mode
-
The script may create menus and bind them to actions - when the menu is selected, the action is executed
-
The script may bind to events that will be generated asynchronously by pcb-rnd - when such an event is received, the script executes some code
-
The script may register new exporter(s) - the user will be able to export the design using the script
-
The script may run arbitrary code "on load" (when the script is loaded) - however, that time the design or even the GUI may not be loaded/initialized yet - this is useful for registering actions, bind to events or set up exporters
-
-
-
-
2. GPMI intro
-
-
2.1. GPMI's place in the pcb-rnd world
-
-GPMI is a plugin/buildin HID. Instead of doing actual work, it loads scripts
-and provides a glue layer between pcb-rnd and the scripts. The actual work
-is performed by the scripts.
-The glue layer comes in two kinds:
-
-
gpmi module: dynamic lib written in C, knows how to load and interpret a script and how to deliver events to the script
-
gpmi package: dynamic lib, provides C functions the script can directly call; package functions then know how to deal with PCB internals
-
-Arrows drawn with dashed line represents a slow, string based communication.
-
-
-
2.2. Module, script, script context, packages
-
-Each time a script needs to be loaded, first a module is loaded and the name
-of the script is passed to the module. During module initialization, the module
-sets up a script interpreter and script context and loads the script into the
-context.
-
-If there are 3 separate lua scripts running in pcb-rnd, there are 3 separate
-lua modules loaded, each dealing with one of the scripts. The process of
-loading a script is illustrated by highlighting the relevant paths with red
-for step 1 and green for step 2.
-
-Step 0: the GPMI HID finds a script has to be loaded. The idea comes
-from the config file (pcb-rnd-gpmi.conf) or from the GUI (manage scripts)
-or as a request from a script already loaded.
-
-Step 1: the GPMI HID loads the corresponding module which in turns
-loads the script. The script has a "main" part that is run on load. For
-most languages this is the global code sections; in some languages it is
-a specific function, usually called main. A few basic glue packages
-are already loaded before the script.
-
-Step 2: the script can load glue packages. This usually happens
-from the on-load main part from the script. The actual mechanism is to
-call PkgLoad() from a glue package that was automatically loaded in
-Step 1. The green arrows represent this path: the script executes PkgLoad()
-which in turns loads other package(s) into the GPMI hid.
-
-Packages are loaded only once and are globally accessible for multiple modules.
-
-Binding an event in a script is done by calling the Bind() function
-(this is implemented in a package automatically loaded). The first
-argument is the name of the event, the second argument is the name of
-the script function that should be called when the event is triggered. Both
-arguments are strings. The event binding mechanism is shown in red in the
-map to the right.
-
-The script can create new actions using the action_register() function
-(the actions package needs to be loaded first). A script may register multiple
-actions. This call is marked with green in the above map.
-If any of the actions registered by the script is called, the event "ACTE_action"
-is generated. This has two implications:
-
-
a script that registers actions needs to bind the ACTE_action event to serve the action requests
-
if a script registers multiple actions, in the event handler it needs to check which action triggered the event (e.g. with a switch()-like construction on the event name)
-
-
-
-
-Menus are created using the create_menu() call. Menus can be
-created only when the GUI is already set up - this may happen only
-after some of the scripts are already loaded. Thus scripts shall
-create menus from an event handler bound to the ACTE_gui_init event.
-This event is triggered right after the GUI has been set up.
-On the map to the right the red arrows represent the path of ACTE_gui_init;
-the green arrows represent the reaction of the script, creating the new
-menu.
-
-
-
-
2.4. Exporting
-
-Exporter scripts first have to set up an exporter hid. This typically
-happens from their on-load main part. Related calls are in the hid
-package. The following map shows this process with red arrows:
-
-When the user chooses to use the exporter, among the green arrows,
-a series of events are triggered and the script can generate output
-directly to a file from event handlers bound to these exporting events.
-
-
-
2.5. Making modifications on the design
-The purpose of a script might be to manipulate the objects in the current design.
-Such a script registers actions, and implements the handler of the actions
-using the layout package. The layout package provides calls to query,
-change and create design objects.
-
-
-
3. How it works in practice
-
-
3.1. Loading the GPMI plugin
-Check the output of ./configure, it will tell if gpmi is compiled as buildin
-or plugin (or not at all).
-If the gpmi plugin is compiled as a buildin, it is already loaded, no
-further steps are required.
-
-If gpmi is a plugin, gpmi_plugin.so (or gpmi_plugin.dll) needs to be
-copied in one of the plugin directories pcb-rnd is looking into on startup:
-
-
path
purpose
-
-
$prefix/lib/pcb-rnd/plugins/$arch/
system plugins, multihost
-
$prefix/lib/pcb-rnd/plugins/
system plugins
-
~/.pcb/plugins/$arch/
user plugins, multihost
-
~/.pcb/plugins/
user plugins
-
./plugins/$arch/
project plugins, multihost
-
./plugins/
project plugins
-
-In the above table:
-
-
$prefix is the installation prefix (normally /usr)
-
$arch is the host arch triplet, e.g. i386-unknown-linux; this is useful if multiple architectures share the same NFS mounted plugin dir
-
~ is the user home directory, if exists, e.g. /home/jdoe
-
./ is the current working directory pcb has been started from; may be useful for project-local scripts
-
-
-
3.2. Loading scripts
-The gpmi plugin looks for a file called "pcb-rnd-gpmi.conf" in each of the
-plugin directories. Wherever the file is found, it is loaded and parsed.
-The file is plain text, each line describes a script to be loaded. Empty
-lines and lines starting with # are comments and are ignored.
-
-Script load lines contain two words separated by a space: a module name
-and a script name. Relative paths in the the script name are relative to
-the directory the config file is found in.
-
-Example config:
-
-# load the carc script (written in lua) from next to the config file:
-lua carc.lua
-
-# load foo.awk, whcih is a mawk script, from its installation path
-mawk /usr/lib/foo/foo.awk
-
-Create a function ev_action that will be called when any of
-the actions registered by the script is executed. The script registers
-only one action, so it does not need to check which action caused
-the function to be called.
-
-When the action event is called, use dialog_log to append
-a log message.
-
-In the "main" section of the script, bind event ACTE_action to
-our local function ev_action - this gets ev_action to
-be called when any of the actions registered by this script is executed.
-
-Finally use action_register to register the action:
-
-
first argument is the name of the action
-
second is the xy query string; it is empty since this action won't need coordinates to operate on
-
third is the description that shows up in dumps and helps
-
fourth is the syntax description (also for helps)
-
Create a function
-ev_action
- that will be called when any of the actions registered by the script is executed. The script registers only one action, so it does not need to check which action caused the function to be called.
-
When the action event is called, use
-dialog_log
- to append a log message.
-
In the "main" section of the script, bind event
-ACTE_action
- to our local function
-ev_action
- - this gets
-ev_action
- to be called when any of the actions registered by this script is executed.
-
-Create a function ev_action that will be called when any of
-the actions registered by the script is executed. The script registers
-only one action, so it does not need to check which action caused
-the function to be called.
-
-When the action event is called, use dialog_report to pop
-up a report dialog. First argument donates the name (title) of the window,
-the second is the text printed in the window.
-
-In the "main" section of the script, bind event ACTE_action to
-our local function ev_action - this gets ev_action to
-be called when any of the actions registered by this script is executed.
-
-Finally use action_register to register the action:
-
-
first argument is the name of the action
-
second is the xy query string; it is empty since this action won't need coordinates to operate on
-
third is the description that shows up in dumps and helps
-
fourth is the syntax description (also for helps)
-
Create a function
-ev_action
- that will be called when any of the actions registered by the script is executed. The script registers only one action, so it does not need to check which action caused the function to be called.
-
When the action event is called, use
-dialog_report
- to pop up a report dialog. First argument donates the name (title) of the window, the second is the text printed in the window.
-
In the "main" section of the script, bind event
-ACTE_action
- to our local function
-ev_action
- - this gets
-ev_action
- to be called when any of the actions registered by this script is executed.
-
layout for searching selected objects and moving objects.
-
-
-Create a function ev_action that will be called when any of
-the actions registered by the script is executed. The script registers
-only one action, so it does not need to check which action caused
-the function to be called.
-
-When the action event is called, first set up:
-
-
fetch event argument 0 and 1 using action_arg;
-
resolve the conversion rate from mm to PCB's units using mm2pcb_multiplier;
-
perform a search for all selected object using layout_search_selected (return value is the number of objects found), name the resulting list "mv_search"
-
-A loop then iterates over the objects on the list:
-
-
resolve the Nth element of the list using layout_search_get, referecing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer;
-
move the object using layout_obj_move; specify the object pointer, then which part of the object should be moved ("OC_OBJ" means the whole object) and relative offsets (dx and dy calculated earlier)
-
-Finally the search list shall be destroyed to reclaim memory, using layout_search_free.
-
-
-In the "main" section of the script, bind event ACTE_action to
-our local function ev_action - this gets ev_action to
-be called when any of the actions registered by this script is executed.
-
-Finally use action_register to register the action:
-
-
first argument is the name of the action
-
second is the xy query string; it is empty since this action won't need coordinates to operate on
-
third is the description that shows up in dumps and helps
-
fourth is the syntax description (also for helps)
-
-layout
- for searching selected objects and moving objects.
-
-
Create a function
-ev_action
- that will be called when any of the actions registered by the script is executed. The script registers only one action, so it does not need to check which action caused the function to be called.
-
When the action event is called, first set up:
-
-
fetch event argument 0 and 1 using
-action_arg
-;
-
resolve the conversion rate from mm to PCB's units using
-mm2pcb_multiplier
-;
-
perform a search for all selected object using
-layout_search_selected
- (return value is the number of objects found), name the resulting list "mv_search"
- A loop then iterates over the objects on the list:
-
-
resolve the Nth element of the list using
-layout_search_get
-, referecing the list by name ("mv_search") and specifying which element to get (the Nth); the result is an object pointer;
-
move the object using
-layout_obj_move
-; specify the object pointer, then which part of the object should be moved ("OC_OBJ" means the whole object) and relative offsets (dx and dy calculated earlier)
- Finally the search list shall be destroyed to reclaim memory, using
-layout_search_free
-.
-
In the "main" section of the script, bind event
-ACTE_action
- to our local function
-ev_action
- - this gets
-ev_action
- to be called when any of the actions registered by this script is executed.
-
second is the xy query string; it is empty since this action won't need coordinates to operate on
-
third is the description that shows up in dumps and helps
-
fourth is the syntax description (also for helps)
-
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ID.name
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ID.name (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ID.name (nonexistent)
@@ -1 +0,0 @@
-action: move selected objects
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ex.lua
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ex.lua (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ex.lua (nonexistent)
@@ -1,18 +0,0 @@
-PkgLoad("pcb-rnd-gpmi/actions", 0);
-PkgLoad("pcb-rnd-gpmi/layout", 0);
-
-function ev_action(id, name, argc, x, y)
- local dx = action_arg(0) * mm2pcb_multiplier()
- local dy = action_arg(1) * mm2pcb_multiplier()
-
- local num_objs = layout_search_selected("mv_search", "OM_ANY")
- for n=0,num_objs+1
- do
- obj_ptr = layout_search_get("mv_search", n)
- layout_obj_move(obj_ptr, "OC_OBJ", dx, dy)
- end
- layout_search_free("mv_search")
-end
-
-Bind("ACTE_action", "ev_action");
-action_register("mv", "", "move selected objects by dx and dy mm", "mv(dx,dy)");
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ex.tcl
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ex.tcl (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ex.tcl (nonexistent)
@@ -1,17 +0,0 @@
-PkgLoad pcb-rnd-gpmi/actions 0
-PkgLoad pcb-rnd-gpmi/layout 0
-
-proc ev_action {id, name, argc, x, y} {
- set dx [expr round([action_arg 0] * [mm2pcb_multiplier])]
- set dy [expr round([action_arg 1] * [mm2pcb_multiplier])]
-
- set num_objs [layout_search_selected mv_search OM_ANY]
- for {set n 0} {$n < $num_objs} {incr n} {
- set obj_ptr [layout_search_get mv_search $n]
- layout_obj_move $obj_ptr OC_OBJ $dx $dy
- }
- layout_search_free mv_search
-}
-
-Bind ACTE_action ev_action
-action_register "mv" "" "move selected objects by dx and dy mm" "mv(dx,dy)"
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ex.scm
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ex.scm (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ex.scm (nonexistent)
@@ -1,20 +0,0 @@
-(PkgLoad "pcb-rnd-gpmi/actions" 0)
-(PkgLoad "pcb-rnd-gpmi/layout" 0)
-
-(define ev_action (lambda (id name argc x y)
-(let
- (
- (dx (* (string->number (action_arg 0)) (string->number (mm2pcb_multiplier))))
- (dy (* (string->number (action_arg 1)) (string->number (mm2pcb_multiplier))))
- (num_objs (string->number (layout_search_selected "mv_search" "OM_ANY")))
- (obj_ptr 0)
- )
- (do ((n 0 (1+ n)))
- ((> n num_objs))
- (set! obj_ptr (layout_search_get "mv_search" n))
- (layout_obj_move obj_ptr "OC_OBJ" (inexact->exact dx) (inexact->exact dy))
- )
-)))
-
-(Bind "ACTE_action" "ev_action")
-(action_register "mv" "" "move selected objects by dx and dy mm" "mv(dx,dy)")
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ex.awk
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ex.awk (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ex.awk (nonexistent)
@@ -1,22 +0,0 @@
-BEGIN {
- PkgLoad("pcb-rnd-gpmi/actions", 0);
- PkgLoad("pcb-rnd-gpmi/layout", 0);
-}
-
-function ev_action(id, name, argc, x, y ,dx,dy,n,num_objs,obj_ptr)
-{
- dx = action_arg(0) * mm2pcb_multiplier()
- dy = action_arg(1) * mm2pcb_multiplier()
-
- num_objs = layout_search_selected("mv_search", "OM_ANY")
- for(n = 0; n < num_objs; n++) {
- obj_ptr = layout_search_get("mv_search", n)
- layout_obj_move(obj_ptr, "OC_OBJ", dx, dy)
- }
- layout_search_free("mv_search")
-}
-
-BEGIN {
- Bind("ACTE_action", "ev_action");
- action_register("mv", "", "move selected objects by dx and dy mm", "mv(dx,dy)");
-}
Index: trunk/doc-rnd/gpmi/rosetta/30_move/ex.rb
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/30_move/ex.rb (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/30_move/ex.rb (nonexistent)
@@ -1,25 +0,0 @@
-PkgLoad("pcb-rnd-gpmi/actions", 0);
-PkgLoad("pcb-rnd-gpmi/layout", 0);
-
-def ev_action(id, name, argc, x, y)
-# TODO: how to convert 1e+06 in ruby?
-# conv = mm2pcb_multiplier().to_i
- conv = 1000000
-
-
- dx = action_arg(0).to_i * conv.to_i;
- dy = action_arg(1).to_i * conv.to_i;
-
- num_objs = layout_search_selected("mv_search", "OM_ANY").to_i;
-
- for n in 0..(num_objs-1)
- obj_ptr = layout_search_get("mv_search", n);
- layout_obj_move(obj_ptr, "OC_OBJ", dx, dy);
- n += 1;
- end
- layout_search_free("mv_search");
-
-end
-
-Bind("ACTE_action", "ev_action");
-action_register("mv", "", "move selected objects by dx and dy mm", "mv(dx,dy)");
Index: trunk/doc-rnd/gpmi/rosetta/12_hello_menu/ex.html
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/12_hello_menu/ex.html (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/12_hello_menu/ex.html (nonexistent)
@@ -1,33 +0,0 @@
-Load packages the script depends on:
-
-
actions for registering the new action;
-
dialogs for creating a dialog box.
-
-
-Create a function ev_action that will be called when any of
-the actions registered by the script is executed. The script registers
-only one action, so it does not need to check which action caused
-the function to be called.
-
-When the action event is called, use dialog_report to pop
-up a report dialog. First argument donates the name (title) of the window,
-the second is the text printed in the window.
-
-Create a function ev_gui_init that will be called when the
-gui has been initialized - this is the right moment to register
-new menus in the GUI. Put the new menu item in the
-"Plugins/GPMI scripting/" menu by convention, and set hot key to ctrl+w.
-The menu should execute action hello().
-
-In the "main" section of the script, bind event ACTE_action to
-our local function ev_action - this gets ev_action to
-be called when any of the actions registered by this script is executed.
-Also bind ev_gui_init so that the new menu can be safely created.
-
-Finally use action_register to register the action:
-
-
first argument is the name of the action
-
second is the xy query string; it is empty since this action won't need coordinates to operate on
-
third is the description that shows up in dumps and helps
-
fourth is the syntax description (also for helps)
-
Create a function
-ev_action
- that will be called when any of the actions registered by the script is executed. The script registers only one action, so it does not need to check which action caused the function to be called.
-
When the action event is called, use
-dialog_report
- to pop up a report dialog. First argument donates the name (title) of the window, the second is the text printed in the window.
-
Create a function
-ev_gui_init
- that will be called when the gui has been initialized - this is the right moment to register new menus in the GUI. Put the new menu item in the "Plugins/GPMI scripting/" menu by convention, and set hot key to ctrl+w. The menu should execute action hello().
-
In the "main" section of the script, bind event
-ACTE_action
- to our local function
-ev_action
- - this gets
-ev_action
- to be called when any of the actions registered by this script is executed. Also bind ev_gui_init so that the new menu can be safely created.
-
-The Rosetta Stone
-of pcb-rnd scripting is a collection of example scripts implemented in
-various scripting languages. Rosetta has multiple purposes:
-
-
to provide examples of using the pcb-rnd API;
-
to not scare away newcomers by showing the first examples in an unfamiliar language;
-
to help the user to decide which language to use for a specific task;
-
to provide examples on how to convert idioms of pcb-rnd scripts from one language to another.
-
-
-Each example comes with an explanation, written in plain English about what the
-scripts do, step by step. Instead of trying to exploit powerful features
-of the language, example implementations try to be simple.
-
-The list below is ordered from the least complex to the most complex examples.
-Column lvl is the complexity score. The less the score is, the simpler
-the example is.
-
-
-
-The Rosetta Stone
-of pcb-rnd scripting is a collection of example scripts implemented in
-various scripting languages. Rosetta has multiple purposes:
-
-
to provide examples of using the pcb-rnd API;
-
to not scare away newcomers by showing the first examples in an unfamiliar language;
-
to help the user to decide which language to use for a specific task;
-
to provide examples on how to convert idioms of pcb-rnd scripts from one language to another.
-
-
-Each example comes with an explanation, written in plain English about what the
-scripts do, step by step. Instead of trying to exploit powerful features
-of the language, example implementations try to be simple.
-
-The list below is ordered from the least complex to the most complex examples.
-Column lvl is the complexity score. The less the score is, the simpler
-the example is.
-
-
-
Index of examples
-
-
-
-
-
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.html
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.html (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.html (nonexistent)
@@ -1,60 +0,0 @@
-
-An exporter is a hid registered. During the export
-process, pcb-rnd calls the exporter to draw objects on layers. The GPMI
-layer converts these calls to bindable events. An exporter script catches
-the drawing events relevant to the output format and draws everything from
-event handlers.
-
-An exporter is sort of a drawing backend: pcb-rnd sets up graphic contexts
-(gc for short) and draws on them. The first gc set up should open the
-output file, the last gc closed should flush/close the file.
-
-
-
-
Theory of operation
-Assume only filled circles on the
-top assembly layer are holes. Emit a line for each of these
-and ignore everything else.
-
-
Implementation
-Load packages the script depends on:
-
-
hid for registering the new exporter;
-
layout for unit conversion;
-
dialogs for error reporting.
-
-
-Set up an exporter hid, storing the handle of each object created in
-a global variable:
-
-
create a hid using hid_create
-
add two attributes (fields) to the dialog using hid_add_attribute
-
register the new hid using hid_register - this makes it an exporter
-
-
-Set up global state variables:
-
-
fmt will be a cache for the format selected by the user
-
conv is the conversion scale between mm and PCB internal coordinate unit
-
channel specifies a file handle or indicates that the output file is open
-
green_light indicates that the exporter is drawing the relevant layer
-
-
-Define a make_gc callback. It is called when a new graphic
-context is created (e.g. for layers). An exporter is sort of a drawing
-backend: pcb-rnd sets up gc's and draws on them. The first gc set up
-should open the output file, the last gc closed should flush/close the file.
-Define a destroy_gc callback for the latter. GCs are
-destroyed at the end of the export process. Use global variable channel
-to make sure the file is open/close only once (see TODO script context).
-
-Define a set_layer callback that sets green_light to true if
-layer name is "topasssembly", false otherwise.
-
-Callback fill_circle is the workhorse: check if we have the green
-light to emit lines, then convert coordinates and diameter to mm and
-decide what format to use for printing a line for each filled circle.
-
-Finally, bind all four callbacks to exporter events.
-
-
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.desc
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.desc (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.desc (nonexistent)
@@ -1 +0,0 @@
-Create a new exporter that prints a list of drills in x,y,dia table in CSV, TSV or text format
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/index.html
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/index.html (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/index.html (nonexistent)
@@ -1,71 +0,0 @@
-
-
- An exporter is a hid registered. During the export process, pcb-rnd calls the exporter to draw objects on layers. The GPMI layer converts these calls to bindable events. An exporter script catches the drawing events relevant to the output format and draws everything from event handlers.
-
An exporter is sort of a drawing backend: pcb-rnd sets up graphic contexts (gc for short) and draws on them. The first gc set up should open the output file, the last gc closed should flush/close the file.
-
-
-
Theory of operation
- Assume only
-filled circles
- on the
-top assembly layer
- are holes. Emit a line for each of these and ignore everything else.
-
Implementation
- Load packages the script depends on:
-
-
-hid
- for registering the new exporter;
-
-layout
- for unit conversion;
-
-dialogs
- for error reporting.
-
-
Set up an exporter hid, storing the handle of each object created in a global variable:
-
add two attributes (fields) to the dialog using
-hid_add_attribute
-
-
register the new hid using
-hid_register
- - this makes it an exporter
-
-
Set up global state variables:
-
-
fmt will be a cache for the format selected by the user
-
conv is the conversion scale between mm and PCB internal coordinate unit
-
channel specifies a file handle or indicates that the output file is open
-
green_light indicates that the exporter is drawing the relevant layer
-
-
Define a
-make_gc
- callback. It is called when a new graphic context is created (e.g. for layers). An exporter is sort of a drawing backend: pcb-rnd sets up gc's and draws on them. The first gc set up should open the output file, the last gc closed should flush/close the file. Define a
-destroy_gc
- callback for the latter. GCs are destroyed at the end of the export process. Use global variable
-channel
- to make sure the file is open/close only once (see TODO
-script context
-).
-
Define a
-set_layer
- callback that sets green_light to true if layer name is "topasssembly", false otherwise.
-
Callback
-fill_circle
- is the workhorse: check if we have the green light to emit lines, then convert coordinates and diameter to mm and decide what format to use for printing a line for each filled circle.
-
Finally, bind all four callbacks to exporter events.
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.name
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.name (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ID.name (nonexistent)
@@ -1 +0,0 @@
-drill list exporter
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.lua
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.lua (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.lua (nonexistent)
@@ -1,65 +0,0 @@
-PkgLoad("pcb-rnd-gpmi/hid", 0)
-PkgLoad("pcb-rnd-gpmi/layout", 0)
-PkgLoad("pcb-rnd-gpmi/dialogs", 0)
-
-hid = hid_create("drill", "drill list export")
-attr_path = hid_add_attribute(hid, "filename", "name of the output file", "HIDA_Path", 0, 0, "drill.txt")
-attr_format = hid_add_attribute(hid, "format", "file format", "HIDA_Enum", 0, 0, "CSV|TSV|text")
-hid_register(hid)
-
-fmt = 0
-conv = mm2pcb_multiplier()
-channel = nil
-green_light = 0
-
-function make_gc(event_id, hid, gc)
- if channel == nil
- then
- channel = io.open(hid_get_attribute(hid, attr_path), "w")
- if channel == nil
- then
- dialog_report("Error exporting drill", "Could not open file [hid_get_attribute $hid $attr_path] for\nwriting, exporting drill failed.")
- return
- end
- fmt = hid_get_attribute(hid, attr_format)
- end
-end
-
-function destroy_gc(event_id, hid, gc)
- if channel ~= nil
- then
- channel:close()
- channel = nil
- end
-end
-
-function set_layer_group(event_id, hid, group, layer, flags, empty)
- if (layer_flag_is_set(flags, "LYT_ASSY") == "1") and (layer_flag_is_set(flags, "LYT_TOP") == "1")
- then
- green_light = 1
- else
- green_light = 0
- end
-end
-
-function fill_circle(event_id, hid, gc, cx, cy, r)
- if green_light == 1
- then
- cx = cx / conv
- cy = cy / conv
- local dia = r / conv * 2
-
- if fmt == "CSV" then
- channel:write(cx .. "," .. cy .. "," .. dia .. "\n")
- elseif (fmt == "TSV") then
- channel:write(cx .. "\t" .. cy .. "\t" .. dia .. "\n")
- elseif (fmt == "text") then
- channel:write(cx .. " " .. cy .. " " .. dia .. "\n")
- end
- end
-end
-
-Bind("HIDE_make_gc", "make_gc")
-Bind("HIDE_destroy_gc", "destroy_gc")
-Bind("HIDE_set_layer_group", "set_layer_group")
-Bind("HIDE_fill_circle", "fill_circle")
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.tcl
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.tcl (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.tcl (nonexistent)
@@ -1,65 +0,0 @@
-PkgLoad pcb-rnd-gpmi/hid 0
-PkgLoad pcb-rnd-gpmi/layout 0
-PkgLoad pcb-rnd-gpmi/dialogs 0
-
-set hid [hid_create "drill" "drill list export"]
-set attr_path [hid_add_attribute $hid "filename" "name of the output file" "HIDA_Path" 0 0 "drill.txt"]
-set attr_format [hid_add_attribute $hid "format" "file format" "HIDA_Enum" 0 0 "CSV|TSV|text"]
-hid_register $hid
-
-set fmt 0
-set conv [mm2pcb_multiplier]
-set channel -1
-set green_light 0
-
-proc make_gc {event_id hid gc} {
- global channel attr_path attr_format fmt
-
- if {$channel == -1} {
- if {[catch {open [hid_get_attribute $hid $attr_path] "w"} channel]} {
- dialog_report "Error exporting drill" "Could not open file [hid_get_attribute $hid $attr_path] for\nwriting, exporting drill failed."
- return
- }
- set fmt [hid_get_attribute $hid $attr_format]
- }
-}
-
-proc destroy_gc {event_id hid gc} {
- global channel
-
- if {$channel > -1} {
- close $channel
- set channel -1
- }
-}
-
-proc set_layer_group {event_id hid group layer flags empty} {
- global green_light
-
- if { [layer_flag_is_set $flags "LYT_ASSY"] && [layer_flag_is_set $flags "LYT_TOP"] } { set green_light 1; puts "!!!!!!!!!!!!!!!"} { set green_light 0 }
-}
-
-proc fill_circle {event_id hid gc cx cy r} {
- global channel conv fmt green_light
-
- if {$green_light} {
- set cx [expr $cx / $conv]
- set cy [expr $cy / $conv]
- set dia [expr $r / $conv * 2]
-
- if {$fmt eq "CSV"} {
- puts $channel "$cx,$cy,$dia"
- } elseif {$fmt eq "TSV"} {
- puts $channel "$cx $cy $dia"
- } elseif {$fmt eq "text"} {
- puts $channel "$cx $cy $dia"
- }
- }
-}
-
-Bind HIDE_make_gc make_gc
-Bind HIDE_destroy_gc destroy_gc
-Bind HIDE_set_layer_group set_layer_group
-Bind HIDE_fill_circle fill_circle
-
-puts "NA?"
Index: trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.awk
===================================================================
--- trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.awk (revision 5606)
+++ trunk/doc-rnd/gpmi/rosetta/35_export_drill/ex.awk (nonexistent)
@@ -1,60 +0,0 @@
-BEGIN {
- PkgLoad("pcb-rnd-gpmi/hid", 0)
- PkgLoad("pcb-rnd-gpmi/layout", 0)
- PkgLoad("pcb-rnd-gpmi/dialogs", 0)
-
- hid = hid_create("drill", "drill list export")
- attr_path = hid_add_attribute(hid, "filename", "name of the output file", "HIDA_Path", 0, 0, "drill.txt")
- attr_format = hid_add_attribute(hid, "format", "file format", "HIDA_Enum", 0, 0, "CSV|TSV|text")
- hid_register(hid)
-
- fmt = 0
- conv = mm2pcb_multiplier()
- channel = ""
- green_light = 0
-}
-
-function make_gc(event_id, hid, gc) {
- if (channel == "") {
- channel = hid_get_attribute(hid, attr_path)
-# awk: can't check whether the file can be open here
- fmt = hid_get_attribute(hid, attr_format)
- }
-}
-
-function destroy_gc(event_id, hid, gc) {
- if (channel != "") {
- close(channel)
- channel = ""
- }
-}
-
-function set_layer(event_id, hid, group, layer, flags, empty) {
- if ((layer_flag_is_set(flags, "LYT_ASSY") == "1") && (layer_flag_is_set(flags, "LYT_TOP") == "1"))
- green_light = 1
- else
- green_light = 0
-}
-
-function fill_circle(event_id, hid, gc, cx, cy, r ,dia) {
- if (green_light) {
- cx = cx / conv
- cy = cy / conv
- dia = r / conv * 2
-
- if (fmt == "CSV") {
- print cx "," cy "," dia > channel
- } else if (fmt == "TSV") {
- print cx "\t" cy "\t" dia > channel
- } else if (fmt == "text") {
- print cx " " cy " " dia > channel
- }
- }
-}
-
-BEGIN {
- Bind("HIDE_make_gc", "make_gc")
- Bind("HIDE_destroy_gc", "destroy_gc")
- Bind("HIDE_set_layer_group", "set_layer_group")
- Bind("HIDE_fill_circle", "fill_circle")
-}
Index: trunk/doc-rnd/gpmi/gpmi_flow_exp.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/gpmi/gpmi_flow_exp.png
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_exp.png (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_exp.png (nonexistent)
Property changes on: trunk/doc-rnd/gpmi/gpmi_flow_exp.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi/Porting
===================================================================
--- trunk/doc-rnd/gpmi/Porting (revision 5606)
+++ trunk/doc-rnd/gpmi/Porting (nonexistent)
@@ -1,5 +0,0 @@
-Currently the project works on Linux only. GPMI is portable, so we need
-only Makefile tweakings on pcb-gpmi to be able to compile it anywhere
-where GPMI compiles. However, first I want to see some test results
-from Linux users.
-
Index: trunk/doc-rnd/gpmi/gpmi_flow_exp.dot
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_exp.dot (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_exp.dot (nonexistent)
@@ -1,65 +0,0 @@
-digraph g {
- rankdir=LR
- splines="polyline"
-# nodesep=1
-# ranksep=1.5
-
- subgraph cluster_0 {
- label="pcb-rnd"
-# core [label="pcb-rnd core|{{HID system|plugin system}}" shape=record]
- core [label="core" shape=box]
- hids [label="HID system" shape=box height=2]
- plugins [label="plugin system" shape=box height=2]
- }
-
- subgraph cluster_1 {
- label="GPMI"
- gpmi_hid [label="gpmi HID"]
- gpmi_pkg [label="gpmi package\n(host glue layer)"]
- gpmi_mod1 [label="gpmi lua module\n(script glue layer)"]
- gpmi_scr1 [label="lua script"]
- gpmi_mod2 [label="gpmi mawk module\n(script glue layer)"]
- gpmi_scr2 [label="awk script"]
- outfile [label="export\noutput file" color=green]
- }
-
-
-
- gui [label="the active\nGUI HID\n(e.g. gtk)"]
- exp1 [label="PS exporer"]
- exp2 [label="PNG exporer"]
-
-
- exp1 -> hids [label="register"]
- exp2 -> hids [label="register"]
-
- hids -> exp1 [label="drawing"]
- hids -> exp2 [label="drawing"]
- hids -> gui [label="drawing"]
-
- plugins -> gpmi_hid [label="load plugin"]
- gpmi_hid -> hids [label="register"]
- hids -> gpmi_hid [label="drawing" color=green]
- core -> gpmi_hid [label="event"]
-
- gpmi_pkg -> core [label="calls & variables"]
- gpmi_pkg -> hids [label="calls & variables" color=red]
- gpmi_pkg -> gpmi_hid [label="calls & variables"]
- gpmi_pkg -> plugins [label="calls & variables"]
-
-
- gpmi_hid -> gpmi_mod1 [label="load script"]
- gpmi_hid -> gpmi_mod1 [label="event" color=green]
- gpmi_hid -> gpmi_mod2 [label="load script"]
- gpmi_hid -> gpmi_mod2 [label="event"]
-
- gpmi_mod1 -> gpmi_scr1 [label="load and exec"]
- gpmi_mod1 -> gpmi_scr1 [label="event" style=dashed color=green]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed color=red]
- gpmi_scr1 -> outfile [label="write" color=green]
-
- gpmi_mod2 -> gpmi_scr2 [label="load and exec"]
- gpmi_mod2 -> gpmi_scr2 [label="event" style=dashed]
- gpmi_scr2 -> gpmi_pkg [label="function calls" style=dashed]
-
-}
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/gpmi_flow_menu.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/gpmi/gpmi_flow_menu.png
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_menu.png (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_menu.png (nonexistent)
Property changes on: trunk/doc-rnd/gpmi/gpmi_flow_menu.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi/gpmi_flow_menu.dot
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_menu.dot (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_menu.dot (nonexistent)
@@ -1,63 +0,0 @@
-digraph g {
- rankdir=LR
- splines="polyline"
-# nodesep=1
-# ranksep=1.5
-
- subgraph cluster_0 {
- label="pcb-rnd"
-# core [label="pcb-rnd core|{{HID system|plugin system}}" shape=record]
- core [label="core" shape=box]
- hids [label="HID system" shape=box height=2]
- plugins [label="plugin system" shape=box height=2]
- }
-
- subgraph cluster_1 {
- label="GPMI"
- gpmi_hid [label="gpmi HID"]
- gpmi_pkg [label="gpmi package\n(host glue layer)"]
- gpmi_mod1 [label="gpmi lua module\n(script glue layer)"]
- gpmi_scr1 [label="lua script"]
- gpmi_mod2 [label="gpmi mawk module\n(script glue layer)"]
- gpmi_scr2 [label="awk script"]
- }
-
-
-
- gui [label="the active\nGUI HID\n(e.g. gtk)"]
- exp1 [label="PS exporer"]
- exp2 [label="PNG exporer"]
-
-
- exp1 -> hids [label="register"]
- exp2 -> hids [label="register"]
-
- hids -> exp1 [label="drawing"]
- hids -> exp2 [label="drawing"]
- hids -> gui [label="drawing" color=green]
-
- plugins -> gpmi_hid [label="load plugin"]
- gpmi_hid -> hids [label="register"]
- hids -> gpmi_hid [label="drawing"]
- core -> gpmi_hid [label="event" color=red]
-
- gpmi_pkg -> core [label="calls & variables"]
- gpmi_pkg -> hids [label="calls & variables" color=green]
- gpmi_pkg -> gpmi_hid [label="calls & variables"]
- gpmi_pkg -> plugins [label="calls & variables"]
-
-
- gpmi_hid -> gpmi_mod1 [label="load script"]
- gpmi_hid -> gpmi_mod1 [label="event" color=red]
- gpmi_hid -> gpmi_mod2 [label="load script"]
- gpmi_hid -> gpmi_mod2 [label="event"]
-
- gpmi_mod1 -> gpmi_scr1 [label="load and exec"]
- gpmi_mod1 -> gpmi_scr1 [label="event" style=dashed color=red]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed color=green]
-
- gpmi_mod2 -> gpmi_scr2 [label="load and exec"]
- gpmi_mod2 -> gpmi_scr2 [label="event" style=dashed]
- gpmi_scr2 -> gpmi_pkg [label="function calls" style=dashed]
-
-}
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/Credits
===================================================================
--- trunk/doc-rnd/gpmi/Credits (revision 5606)
+++ trunk/doc-rnd/gpmi/Credits (nonexistent)
@@ -1,11 +0,0 @@
-2006...2009
-~~~~~~~~~~~
-Big thanks to DJ Delorie who added external HID support in PCB and commited
-many small patches needed to get this project working in the period
-when the whole project was a plugin to vanilla pcb.
-
-The following people helped the project with their valuable feedbacks
-in the early stage:
- John Griessen
- Carlos Nieves Onega
-
Index: trunk/doc-rnd/gpmi/History
===================================================================
--- trunk/doc-rnd/gpmi/History (revision 5606)
+++ trunk/doc-rnd/gpmi/History (nonexistent)
@@ -1,32 +0,0 @@
-History
-~~~~~~~
-As of October 2006, PCB has native support for external (or dynamic
-loadable) HIDs. This project is plugin that provides scripting features.
-
-For a long time I believe that good applications should be scriptable,
-and real good ones should not restrict scripting to one or two languages.
-For this reason I have been working on GPMI with various other developers
-for years. GPMI provides a general way to split up big applications in
-smaller, usually dynamic loadable parts, and encourages that some of these
-parts should be written in a script language. For me, the ideal model
-of an application is a small core that knows how to manipulate the
-internal representation of the task and a lot of dynamic functionality
-plugins and support plugins that do all the high-level job for the user.
-
-PCB is an old and big software, with a stable user base. Restructuring the
-whole source to "GPMIize" it is no option. Instead, a nice compromise is
-implementing this functionality in a plugin that pcb can load for the users
-who are interested in such extras.
-
-From 2006 to 2009 spring the project was on hold, because I was nagging
-PCB developers to add support for customizable dialog boxes. In late March
-2009, PCB developers pointed out that the interface I was waiting for had been
-there for who-knows-how-long. With the help of DJ Delorie I extended the
-action handling of PCB to remember action contexts, which was another showstopper.
-After all obstacles removed, I allocated a 24 hour coding session where I
-finished the exporter functionality, added action binding, dialog box handling
-and layout manipulation functions.
-
-During the summer of 2015 I merged pcb-gpmi into pcb-rnd and made it
-the default scirpting engine for pcb-rnd.
-
Index: trunk/doc-rnd/gpmi/gpmi_flow_reg.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/gpmi/gpmi_flow_reg.png
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_reg.png (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_reg.png (nonexistent)
Property changes on: trunk/doc-rnd/gpmi/gpmi_flow_reg.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi/gpmi_flow_reg.dot
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_reg.dot (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_reg.dot (nonexistent)
@@ -1,64 +0,0 @@
-digraph g {
- rankdir=LR
- splines="polyline"
-# nodesep=1
-# ranksep=1.5
-
- subgraph cluster_0 {
- label="pcb-rnd"
-# core [label="pcb-rnd core|{{HID system|plugin system}}" shape=record]
- core [label="core" shape=box]
- hids [label="HID system" shape=box height=2]
- plugins [label="plugin system" shape=box height=2]
- }
-
- subgraph cluster_1 {
- label="GPMI"
- gpmi_hid [label="gpmi HID"]
- gpmi_pkg [label="gpmi package\n(host glue layer)"]
- gpmi_mod1 [label="gpmi lua module\n(script glue layer)"]
- gpmi_scr1 [label="lua script"]
- gpmi_mod2 [label="gpmi mawk module\n(script glue layer)"]
- gpmi_scr2 [label="awk script"]
- }
-
-
-
- gui [label="the active\nGUI HID\n(e.g. gtk)"]
- exp1 [label="PS exporer"]
- exp2 [label="PNG exporer"]
-
-
- exp1 -> hids [label="register"]
- exp2 -> hids [label="register"]
-
- hids -> exp1 [label="drawing"]
- hids -> exp2 [label="drawing"]
- hids -> gui [label="drawing"]
-
- plugins -> gpmi_hid [label="load plugin"]
- gpmi_hid -> hids [label="register"]
- hids -> gpmi_hid [label="drawing"]
- core -> gpmi_hid [label="event"]
-
- gpmi_pkg -> core [label="calls & variables" color=green]
- gpmi_pkg -> hids [label="calls & variables"]
- gpmi_pkg -> gpmi_hid [label="calls & variables" color=red]
- gpmi_pkg -> plugins [label="calls & variables"]
-
-
- gpmi_hid -> gpmi_mod1 [label="load script"]
- gpmi_hid -> gpmi_mod1 [label="event"]
- gpmi_hid -> gpmi_mod2 [label="load script"]
- gpmi_hid -> gpmi_mod2 [label="event"]
-
- gpmi_mod1 -> gpmi_scr1 [label="load and exec"]
- gpmi_mod1 -> gpmi_scr1 [label="event" style=dashed]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed color=red]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed color=green]
-
- gpmi_mod2 -> gpmi_scr2 [label="load and exec"]
- gpmi_mod2 -> gpmi_scr2 [label="event" style=dashed]
- gpmi_scr2 -> gpmi_pkg [label="function calls" style=dashed]
-
-}
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/gpmi_flow_load.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/gpmi/gpmi_flow_load.png
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_load.png (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_load.png (nonexistent)
Property changes on: trunk/doc-rnd/gpmi/gpmi_flow_load.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi/gpmi_flow.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/gpmi/gpmi_flow.png
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow.png (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow.png (nonexistent)
Property changes on: trunk/doc-rnd/gpmi/gpmi_flow.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/gpmi/gpmi_flow_load.dot
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow_load.dot (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow_load.dot (nonexistent)
@@ -1,63 +0,0 @@
-digraph g {
- rankdir=LR
- splines="polyline"
-# nodesep=1
-# ranksep=1.5
-
- subgraph cluster_0 {
- label="pcb-rnd"
-# core [label="pcb-rnd core|{{HID system|plugin system}}" shape=record]
- core [label="core" shape=box]
- hids [label="HID system" shape=box height=2]
- plugins [label="plugin system" shape=box height=2]
- }
-
- subgraph cluster_1 {
- label="GPMI"
- gpmi_hid [label="gpmi HID"]
- gpmi_pkg [label="gpmi package\n(host glue layer)"]
- gpmi_mod1 [label="gpmi lua module\n(script glue layer)"]
- gpmi_scr1 [label="lua script"]
- gpmi_mod2 [label="gpmi mawk module\n(script glue layer)"]
- gpmi_scr2 [label="awk script"]
- }
-
-
-
- gui [label="the active\nGUI HID\n(e.g. gtk)"]
- exp1 [label="PS exporer"]
- exp2 [label="PNG exporer"]
-
-
- exp1 -> hids [label="register"]
- exp2 -> hids [label="register"]
-
- hids -> exp1 [label="drawing"]
- hids -> exp2 [label="drawing"]
- hids -> gui [label="drawing"]
-
- plugins -> gpmi_hid [label="load plugin" color=red]
- gpmi_hid -> hids [label="register"]
- hids -> gpmi_hid [label="drawing"]
- core -> gpmi_hid [label="event"]
-
- gpmi_pkg -> core [label="calls & variables"]
- gpmi_pkg -> hids [label="calls & variables"]
- gpmi_pkg -> gpmi_hid [label="calls & variables" color=green]
- gpmi_pkg -> plugins [label="calls & variables"]
-
-
- gpmi_hid -> gpmi_mod1 [label="load script" color=red]
- gpmi_hid -> gpmi_mod1 [label="event"]
- gpmi_hid -> gpmi_mod2 [label="load script"]
- gpmi_hid -> gpmi_mod2 [label="event"]
-
- gpmi_mod1 -> gpmi_scr1 [label="load and exec" color=red]
- gpmi_mod1 -> gpmi_scr1 [label="event" style=dashed]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed color=green]
-
- gpmi_mod2 -> gpmi_scr2 [label="load and exec"]
- gpmi_mod2 -> gpmi_scr2 [label="event" style=dashed]
- gpmi_scr2 -> gpmi_pkg [label="function calls" style=dashed]
-
-}
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/gpmi_flow.dot
===================================================================
--- trunk/doc-rnd/gpmi/gpmi_flow.dot (revision 5606)
+++ trunk/doc-rnd/gpmi/gpmi_flow.dot (nonexistent)
@@ -1,63 +0,0 @@
-digraph g {
- rankdir=LR
- splines="polyline"
-# nodesep=1
-# ranksep=1.5
-
- subgraph cluster_0 {
- label="pcb-rnd"
-# core [label="pcb-rnd core|{{HID system|plugin system}}" shape=record]
- core [label="core" shape=box]
- hids [label="HID system" shape=box height=2]
- plugins [label="plugin system" shape=box height=2]
- }
-
- subgraph cluster_1 {
- label="GPMI"
- gpmi_hid [label="gpmi HID"]
- gpmi_pkg [label="gpmi package\n(host glue layer)"]
- gpmi_mod1 [label="gpmi lua module\n(script glue layer)"]
- gpmi_scr1 [label="lua script"]
- gpmi_mod2 [label="gpmi mawk module\n(script glue layer)"]
- gpmi_scr2 [label="awk script"]
- }
-
-
-
- gui [label="the active\nGUI HID\n(e.g. gtk)"]
- exp1 [label="PS exporer"]
- exp2 [label="PNG exporer"]
-
-
- exp1 -> hids [label="register"]
- exp2 -> hids [label="register"]
-
- hids -> exp1 [label="drawing"]
- hids -> exp2 [label="drawing"]
- hids -> gui [label="drawing"]
-
- plugins -> gpmi_hid [label="load plugin"]
- gpmi_hid -> hids [label="register"]
- hids -> gpmi_hid [label="drawing"]
- core -> gpmi_hid [label="event"]
-
- gpmi_pkg -> core [label="calls & variables"]
- gpmi_pkg -> hids [label="calls & variables"]
- gpmi_pkg -> gpmi_hid [label="calls & variables"]
- gpmi_pkg -> plugins [label="calls & variables"]
-
-
- gpmi_hid -> gpmi_mod1 [label="load script"]
- gpmi_hid -> gpmi_mod1 [label="event"]
- gpmi_hid -> gpmi_mod2 [label="load script"]
- gpmi_hid -> gpmi_mod2 [label="event"]
-
- gpmi_mod1 -> gpmi_scr1 [label="load and exec"]
- gpmi_mod1 -> gpmi_scr1 [label="event" style=dashed]
- gpmi_scr1 -> gpmi_pkg [label="function calls" style=dashed]
-
- gpmi_mod2 -> gpmi_scr2 [label="load and exec"]
- gpmi_mod2 -> gpmi_scr2 [label="event" style=dashed]
- gpmi_scr2 -> gpmi_pkg [label="function calls" style=dashed]
-
-}
\ No newline at end of file
Index: trunk/doc-rnd/gpmi/index.html
===================================================================
--- trunk/doc-rnd/gpmi/index.html (revision 5606)
+++ trunk/doc-rnd/gpmi/index.html (nonexistent)
@@ -1,32 +0,0 @@
-
-
-
Events do not have return value. The first argument is always the even id. Event handlers defined in scripts get all event arguments converted to string (types below are informational).
-
-
-
-Layout package searches and manipulates the current layout. Dimension units
-are in nanometer unless otherwise mentioned.
-
-
Page: board dimensions
- Functions used to query or set width and height of the drawing:
-
-
int layout_get_page_width();
-
int layout_get_page_height();
-
void layout_set_page_size(int width, int height);
-
-
-
Layer manipulation
-Most functions perform operations similar to user commands affecting
-the current layer.
-The following few calls can change the current layer. Warning: this is the
-same current layer as the user's; the script most probably wants to save
-the current layer before changing it and then restore it after the operation.
-
-
int layout_resolve_layer(const char *name): resolve layer number by name (case sensitive); returns negative number if not found
-
int layout_get_current_layer(): returns the number of the current layer
-
void layout_switch_to_layer(int layer): switch to layer (further actions will take place there)
-
-
-
-
Object searches
- Search results are collected on lists identified by their name (search_ID).
- If a new search is done with the same name, old search results for that
- name are discarded.
- Search functions return the number of objects found (size of the list) that can
- be then used while querying the results using layout_search_get().
- Results should be freed using layout_search_free() when they are no
- longer needed.
-
- TODO: validity of a list in time
-
-Once the search list is ready, the script can iterate over it and resolve
-the object handle of each object found, using layout_search_get(). Having
-an object handle, The layout_obj_*() functions may be used by the script
-to access fields of an object structure.
-
-
Create new objects
- The layour_create_*() calls are used to create new objects on the current
- layer (set by layout_switch_to_layer()).
-
-
-
-
-The first argument passed to an event handler is always the event ID.
-It is useful if there are several GPMI events with the same arguments and
-the script wants to bind them all to the same event handler. In that case
-using event_id the event handler can determine which event triggered the
-call. This design is similar to the signal handler documented in
-signal(2).
-
-
-
-The case described above (dispatcher in the event handler) is rare.
-Most users will bind one event to one function and can safely ignore this
-argument. Nevertheless it must present as the first argument
-on the event handler's argument list.
-
-
-
Index: trunk/doc-rnd/gpmi/packages/dialogs_ref.html
===================================================================
--- trunk/doc-rnd/gpmi/packages/dialogs_ref.html (revision 5606)
+++ trunk/doc-rnd/gpmi/packages/dialogs_ref.html (nonexistent)
@@ -1,105 +0,0 @@
-
-
when the selected file will be read, not written (HID_FILESELECT_READ)
-
FS_NOT_EXIST
the function calling hid->fileselect will deal with the case when the selected file already exists. If not given, then the gui will prompt with an "overwrite?" prompt. Only used when writing. (HID_FILESELECT_MAY_NOT_EXIST)
-
FS_TEMPLATE
the call is supposed to return a file template (for gerber output for example) instead of an actual file. Only used when writing. (HID_FILESELECT_IS_TEMPLATE)
-
-
-
Functions
-
-
The following functions are registered in script context.
-
-
-
-The action package is used to register actions and menus in PCB and
-to execute existing actions. In PCB actions
-are generated when the user selects a menu, presses a key or issues a
-command on the PCB command line.
-
-
Registration of new actions
-The script may register new actions
-using arbitrary action names. If any of the registered actions is
-detected, an ACTE_action event is sent to the script. If multiple
-actions are used in a script, argument name of the event handler
-can be used to identify the triggering action. (This may be time consuming
-in scripting languages (a series of string comparison) - those scripts
-binding to frequent actions should not bind to too many different actions.)
-pcb-gpmi guarantees that the event handler of a script is triggered only
-when an action is caught that previously was registered by the same script.
-
-The process of binding an action:
-
-
create an event handler for event ACTE_action
-
register one or more actions using function action_register
-
optional: when the event handler is triggered, check argument name (for scripts with multiple actions registered)
-
optional: use argument argc and function action_arg to fetch action arguments
-
optional: use arguments x, y to learn the cursor position on the layout.
-
-
-Example (written in lua):
-
--- load the package
-PkgLoad("pcb-gpmi/actions", 0);
-
--- action callback
-function ev_action(id, name, argc, x, y)
- if name == "cake" then
- size = action_arg(1);
- -- put cake drawing code here
- else
- -- must be candy
- amount = action_arg(1);
- -- put candy drawing code here
- end
-end
-
--- register and bind action
-action_register("cake", "cake center xy?", "cake service", "cake(size)", "");
-action_register("candy", "candy cloud center xy?", "cake service", "candy(amount)", "");
-Bind("ACTE_action", "ev_action");
-
-
-When the script is unloaded all actions the script registered
-are removed from pcb-rnd automatically.
-
-
Executing actions
-An existing action can be executed using the action() call. The only one
-argument is a command line string. The syntyax is the same as in pcb
-command line.
-
-Example (written in lua):
-
-The above script registers a new action called untwo(). When untwo() is executed,
-it exectues action undo() twice.
-
-
-
Creating menus
-It is possible to insert menus and submenus runtime, using the call
-create_menu(). The script should do this only after the gui has been initialized.
-The most common way is to create all menus from the ACTE_gui_init event,
-which is called after the gui finished setting up.
-
-The first argument of create_menu() is the menu path. The path is a list
-of visible menu names separated by slashes (e.g. "/main_menu/File/Save as..." means
-"File" menu, "Save as..." submenu).
-
-Paths are interpreted as menu paths, which are a slightly simplified version
-of lihata paths found in menu.lht. Basically there's a main directory directly
-under root that determines the type of the menu:
-
-
-
/main_menu/ is the menubar
-
/popups/something/ is a popup menu called something; the lesstif HID does
- not support popups; popups are popped up by actions.
-
-
-The simplification compared to lihata paths is that only menu and submenu
-names are on the path, so lihata nodes like "li:submenu" should be ignored.
-In other words, the path represents how the menus can be reached from the user
-interface, plus a "main menu type prefix" as discussed above.
-
-By convention, scripts should
-create new menu items under the "/main_menu/Plugins/" menu.
-
-The following example lua script registers a new menu item
-
-When the user clicks on the menu, the action script specified in the second argument
-of create_menu() is executed. Thus the script usually registers a new action
-first then registers one or more menu items executing those actions.
-
-
-
Index: trunk/doc-rnd/gpmi/packages/hid_ref.html
===================================================================
--- trunk/doc-rnd/gpmi/packages/hid_ref.html (revision 5606)
+++ trunk/doc-rnd/gpmi/packages/hid_ref.html (nonexistent)
@@ -1,205 +0,0 @@
-
-
Events do not have return value. The first argument is always the even id. Event handlers defined in scripts get all event arguments converted to string (types below are informational).
-
-
- The purpose of this package is to expose the dialog box handling interface
- of the active GUI hid. Using this package scripts can pop up dialog boxes
- to inform or ask the user. If there is no active GUI, call logs are dumped
- on stderr. Note: message arguments usually may contain newline (\n) characters
- to split the message.
-
-
Common conventions
- Dialog boxes are blocking calls to the GUI HID: when the script
- calls a dialog box, the script is suspended until the dialog box
- is closed by the user. In other words, dialog boxes behave
- as regular function calls from the scripts: when they return,
- the dialog is over and the result is known.
-
- The only exception is dialog_progress(), which opens or
- updates or closes the already open progress dialog box, and
- returns immediately (even when the box is left open).
-
-
Simple dialogs vs. custom dialogs
- Most of the calls will pop up a static dialog box. Static means
- that widgets are predefined by the GUI HID. The script
- is free to fill in data, but can not change the basic structure of
- the dialog box. For example dialog_confirm(), dialog_prompt(),
- dialog_fileselect() are static.
-
- When the script needs a custom, dynamic dialog box, it needs to
- create an attribute dialog. The script sets up a HID
- structure using the hid package, builds up all the input fields
- then calls dialog_attribute() with the hid.
-
-
Progress dialogs
-
- The script should call dialog_progress() periodicly from a process that
- runs time consuming calculations and check the return value and break
- the loop on cancel. The process should have an idea of how long it
- will take. This is passed on in argument total. As long as
- argument so_far is less than total, the dialog is
- open.
-
- After the process has finished, a call with so_far=total+1 should be
- made to make sure the window is closed. If the call returns non-zero,
- the process should be cancelled.
-
-
-
Index: trunk/doc-rnd/gpmi/packages/hid.html
===================================================================
--- trunk/doc-rnd/gpmi/packages/hid.html (revision 5606)
+++ trunk/doc-rnd/gpmi/packages/hid.html (nonexistent)
@@ -1,76 +0,0 @@
-
-
-
hid package
-
-The hid package has two purposes:
-
-
it is glue layer for exporter dialog boxes and attribute dialog boxes;
-
it can register exporter HIDs in PCB
-
-
-
Building a custom dialog box
-First hid_create() needs to be called. It returns a new hid_t, which is
-an opaq structure for the package that is used to describe attributes of
-an attribute dialog or an exporter hid. Attributes are added using
-hid_add_attribute(), which returns an unique ID of the attribute. The
-attribute ID can be used later for querying attribute value set by the
-user using hid_get_attribute().
-
-The process of building a dialog box is closed by a call to
-
-
hid_register(), which registers a new exporter hid using the
- attributes of the dialog box; or
-
dialog_attribute() (of the dialog package) which pops up a custom
- dialog box immediately.
-
-
-
Registering an exporter
- Function hid_register() registers the hid as an exporter. Should be
- called after all attributes have been added using hid_add_atrtibute().
- The export is coordinated by pcb core; when the user request an export
- using the exporter, a series of events are delivered to the script:
-
-
envelope events to set up exporting
-
many draw events to actually export the objects
-
an envelope event to finish exporting
-
-
-
Envelope: events generated before or after exporting
-
-
HIDE_get_export_options(void *hid): Generated before get_exporter_options returns the option list to the GUI hid
-
HIDE_do_export_start(void *hid): Generated before export redraw starts
-
HIDE_do_export_finish(void *hid): Generated after export redraw finihsed
-
-
-
Drawing: events generated during exporting
- Note: there may be multiple gcs (graphic contexts), each having its own color, line
- properties, xor drawing and faded state. Graphic contexts are created
- and destroyed by the following events:
-
-
HIDE_make_gc(void *hid, void *gc);
-
HIDE_destroy_gc(void *hid, void *gc);
-
-
- Gc properties are changed by the following events:
-
-
HIDE_set_layer(void *hid, const char *name, int group);
-
Copy selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); Unselect(All); Mode(PasteBuffer)
-
Copy selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); Unselect(All); Mode(PasteBuffer)
-
ChangeDrill +5 mil ChangeDrillSize(Object,+5,mil)
-
-
s-alt-shift
-
ChangeDrill -5 mil ChangeDrillSize(Object,-5,mil)
-
-
s-ctrl
-
Save Layout Save(Layout)
-
-
s-ctrl-shift
-
Save Layout As... Save(LayoutAs)
-
-
s-shift
-
ChangeSize -5 mil ChangeSize(Object,-5,mil)
-
-
space
-
Arrow Mode Mode(Arrow)
-
-
t
-
Text Tool scale +10 mil SetValue(TextScale,+10,mil)
-
-
t-shift
-
Text Tool scale -10 mil SetValue(TextScale,-10,mil)
-
-
tab
-
Flip up/down SwapSides(V)
-
-
tab-ctrl
-
Spin 180 degrees SwapSides(R)
-
-
tab-ctrl-shift
-
Swap Sides SwapSides()
-
-
tab-shift
-
Flip left/right SwapSides(H)
-
-
u
-
Undo last operation Undo()
-
-
u-ctrl-shift
-
Clear undo-buffer Undo(ClearList)
-
-
up
-
Step Up Cursor(Warp,0,1,grid)
-
-
up-shift
-
Step +Up Cursor(Pan,0,50,view)
-
-
v-alt
-
Via Tool drill +5 mil SetValue(ViaDrillingHole,+5,mil)
-
-
v-alt-shift
-
Via Tool drill -5 mil SetValue(ViaDrillingHole,-5,mil)
-
-
v-ctrl
-
Paste buffer to layout Mode(PasteBuffer)
-
-
v-ctrl-shift
-
Via Tool size -5 mil SetValue(ViaSize,-5,mil)
-
-
v-shift
-
Via Tool size +5 mil SetValue(ViaSize,+5,mil)
-
-
v e
-
Zoom Max Zoom()
-
-
v f
-
Zoom Max Zoom()
-
-
v i
-
Zoom In 2X Zoom(-2)
-
-
v o
-
Zoom Out 2X Zoom(+2)
-
-
w
-
Add All Rats AddRats(AllRats)
-
-
w-shift
-
AddRats Selected AddRats(SelectedRats)
-
-
x
-
Cycle object being dragged CycleDrag()
-
-
x-ctrl
-
Cut selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); RemoveSelected(); Mode(PasteBuffer)
-
-
x-shift
-
Swap nets on two selected pins net(swap)
-
-
y
-
Puller Puller()
-
-
y-ctrl
-
Redo last undone operation Redo()
-
-
y-shift
-
ChangeSizes to Route style ChangeSizes(Object,style,mil)
-
-
-
Index: trunk/doc-rnd/TODO
===================================================================
--- trunk/doc-rnd/TODO (revision 5606)
+++ trunk/doc-rnd/TODO (nonexistent)
@@ -1,171 +0,0 @@
-- BUGS
- - "unselectable" arc rotated on ps [report:Evan]
- - gerber top layer doesn't have pads on A.pcb (layer cleanup) [report:James]
- - gerber layer group name [report:James]
- ? all route styles deleted when using 'File>load layout data to paste buffer'
- + in the 45-deg line mode, while DRC enforce settings toggled 'on' can cause isolated trace crossing, violating DRC
- - `--dump-actions` and `--show-actions` ends with segmentation fault (compile without debug) Can't reproduce [report:miloh]
- - extend the io_ API so that plugins can be requested to check file headers and decide if they can load the file; this would supress the pcb-related error messages when loading a lihata
- - tab doesn't work in the lesstif hid (was already broken in 1.1.2)
-
-- Lihata persistent save:
- - flag compatibility: save unknown, string-flags as loaded by io_pcb
- - ind: space in ha:layer name
- - ind: symbol height is not in-line on the output
- - ind: indentation bug in via and netlists
- - ind: indentation bug in inline struct therm: closing } is preceded by indentation whitespace for some reason
- - ind: style attribute members in a fresh save
- - keep numeric format: test all
- - keep unknown subtrees
-
-- unravel:
- - replace "outline" and "route" layer name checks with a central layer call
-
-- replace settings with lihata (conf_*)
- - TEST:
- - vendor drill mapping (all functionality, including regex based refdes ignore)
- - route style in gtk and lesstif, save, load, 0, 1 or a lot of styles
- - route style vs. autorouter
-
-- query & advanced search
- - search expr wizard should pick up the expression from the button when clicked
- - field accessors:
- - pad area
- - pin area
- - line (and pad) length and length^2
- - make a run on a large board, speed test, with -O0 and -O3:
- - iteration speed (a simple @)
- - eval speed (a simple @ with a lot of constants in an expr)
- - geo speed
- - regex and string cmp match speed vs. select by name
-
-CLEANUP #5
-- src/check_icon.data - is it used?
-- search for move.dst_layer - don't compare pointer to -1!
-- make uninstall doesn't remove an scm
-- rework the gpmi plugin to make it more standard in regard of the build system and to remove a few directories
-- dir rename trunk/pcblib/tru-hole should handle make correctly and not walk on existing web services or user installs
-- grid status line label doesn't update when using setvalue(grid,delta) add another hook to update this value [miloh]
-- Erich's select undo bug: place an element, select, save & load, unselect, undo 2 times: bad serial
-- Erich's gtk lag report: press 's' a lot then move the mouse - 's' ends up in the new loc!
-- conf: throw an error if user config can not be written
-- the TAB bug: (over ssh -X) press tab for a good 15 seconds; release; it won't work again for a fraction of a second
-- mark bug - ortho shouldn't use it, it should use last point (crosshair.X2); make sure nothing else abuses it [James]
-- conf:
- - remove CFN_INCREMENTS, test if saving increments from preferences works
- - config pov: change prio
- - gtk preferences: check what takes 131 megs of VIRT ram (on top); destroy the dialog structures when closed
- - gtk preferences: poly isle area widget missing from the sizes tab
- - debug why default layer names from the user config are ignored
- - fp_fs_search: kill anything that gets ':' separated string as path list, get a config list instead
- - switch the lesstif HID over from attribs to conf
- - remove redundancy: don't store values in the PCB struct that are in the design conf
- - increments are not really implemented
- - if font file is not found:
- - embedded version?
- - warn when try to write text on pcb?
-- action bug: gui_act.c shouldn't reference Crosshair.X directly; check d-fix.patch about how to fix it
-- next_gui: keep them open, hide
-- look for #warnings
-- fix librarychanged: disable update of gedasymbols on-start, make it an explicit refresh button
-- libstroke: zoom
-- cleanup/rewrite resources:
- - load/swap menus (TODO#1)
- - gpmi:
- - hid: hid_destroy (pair of hid_create)
- - cleanup on unload: remove menus
-- check whether local copy of gts is needed, bisect when toporouter broke
-- check gpmi when pcb-rnd is fully linstalled - broken symlinks?
-- multi-key: display state on the gui
-- implement loglevels and log style tags in the lesstif HID
-- TODO#3: works only on US keyboard
-- gsch2pcb: generalize plugin/buildin loading for external tools, check if gsch2pcb can work from plugins
-
-CLEANUP #6:
-- lihata board/fp format:
- - pads should be polygons (0 long line can't be rotated!)
- - footprint orientation with a vector (just a second point)
-- layer groups from config (e.g. CLI) is ignored
-- res:
- - search for vendor in the hid plugins, there should be no trace of it (vendor should register its in submenus with anchors)
- - re-add dynamic menus after a gui change:
- - either remember dynamic menus in a separate list so they can be rebuilt
- - or provide hooks and let plugins deal with it
- - gpmi: auto-remove menus by cookie (TODO#2)
- - load new res on the fly (replace the menu system):
- - low level reload code (re-add the dynamic menus too!)
- - action to reload if file name is known
- - gui load dialog with tags listed
-- decide about exporter policy:
- - png exports selection (even in not-as-shown), others don't
- - extend png hid attribs with a flag for this, maybe do the same for others
- - document the decision in "hacking"
-- reduce
- - export_bom: rewrite the string list code using htsp and/or lists
- - hash in hid_attrib.c?
- - nelma and gcode both invent .png name locally
- - get rid of gcode/lists.h, and vector.[ch] (autorouter)
- - vendordrill
- - search for /units, replace it with pcb-printf something
- - add round down
- - replace ignore_refdes, ignore_value and ignore_descr with genvector
- - mods:
- - gpmi (and other buildins/plugins) not showing up in the about box
-- self contained
- - files
- - default font
- - action (--show-paths!) and dialog box to print where the actual files are coming from
- - project specific menus from extra lihata files - maybe from project.lht
-- main.c:
- - SIGPIPE - detect it (needed for popen)
-
-CLEANUP #7: the big object split
-- remove pcb_obj_type_t from const.h - use obj_any.h instead
-
-
-
-
-FEATURES
-- BUILD: menuconfig and a config file for scconfig
-
-Low prio:
-- GTK "save as" dialog: there should be an "auto" or "guess by extension" option in the save dialog format
-- insert drag&drop strangeness (mainline too):
- insert should just insert a new point and stop there, not starting a drag&drop
- move; the new point should be marked somehow (e.g. green-find one half of the
- object, like arc split does) lines can be inserted mostly only in all-dir-line
- which is strange
-- missing rotate polygon (mainline too)
-- zoom in too deep onto board edge and the implicit outline rectangle behaves strangely [report:Evan]
-- scconfig: check if it picks up settings from env vars (for a gentoo build)
-- replace mkdtemp() with something safer
-- display net names on pins, vias (and maybe tracks?) when zoomed in enough
-- DRC should warn for thin poly hair
-- rotate shaped vias don't rotate the shape (is via rotated at all?)
-- new examples
- - blinking led with parametric footprints
- - example of nonetlist: 1206 jumpers and logos
-- decide what to do with old doc - texi doesn't seem to work at all
-- rethink/rewrite the action/change infrastructure - too many void *ptr1
- pointers, too many code duplication
-- double sided board, poly on both layers; grab existing lines on one layer and
- move then around. If all layers are visible, redraw of the far side layer
- is slow and causes flickering elements from that layer until the front is
- redrawn. Maybe we should have less flushes?
-- gpmi:
- - dialog: attribute dialog: mini parser from text
- - fix debug draw in the gtk hid
- - ACTE_action(): coords should not be int but Coord
- - get timers to work
-- dmalloc: #include from the bottom from each file. Is this a good idea?!
-- win32 port {large}
- - clean up central Makefile.in rules:
- - remove cat, sed, grep where possible, use scconfig instead
-- arc bug: draw an arc with one end out of the drawing area; it will be jumpy and can not be placed properly
- -> AttachForCopy() calls SetCrosshairRange() that then sets corsshair max* which
- limits the arc to move freely. Problem: this is not arc-specific, this happens with any buffer copy! going for no-design-limit is probably better
-- while drawing a line, the temporary outline should reflect the layer color
-- push&shove
- - keep 45-deg knee when grabbing a point for drag&drop in non-all-dir
-- examine current handling of long options [miloh]
-- --dump-actions shows gpmi paths ( is this related? it looks unexpected to me)
Index: trunk/doc-rnd/index.html
===================================================================
--- trunk/doc-rnd/index.html (revision 5606)
+++ trunk/doc-rnd/index.html (nonexistent)
@@ -1,124 +0,0 @@
-
-
- pcb-rnd - main
-
-
-
-
-
-
-
-
- editor for multilayer Printed Circuit Boards
- scriptable in 10+ different scripting languages
- parametric footprint generation, web footprints
- modular code with a flexible plugin system
- fits well in a UNIXy workflow
- supports CLI and server applications
- active development, frequent releases
- friendly and efficient developer and user community
- predictable development cycles
- compatible with KiCad and gEDA/PCB
-
-
Suported platforms
- Linux desktop (various distributions, from source)
- Mac OS X
- Arch Linux (user package)
-
- IRIX 5.3
- (Likely: any 90's UNIX system with motif)
- Screen resolution as small as 800x600
- GUI options: motif/lesstif, gtk
-
Developers try to respond on user needs, adding features that are actually needed by current users.
-
-
-
-
-
-
- Response Not Delayed
-
Bugrepots, user requests and patches submitted are answered ASAP. There are no patches bitrotting for months. There are no forgotten bugreports.
-
-
-
-
-
-
-
Research & Development
-
-
- Rázós, Nehéz Döntések (Brave, hard decisions)
-
There is a constant experimentation with new features and directions. We are willing to try strange/unusual ideas without risking the stability of the daily workflow.
-
-
-
-
-
-
-
Rants Now Dissipating
-
Instead of talking and ranting a lot about what could work better, we just sit down and make it work better.
-
-
-
-
-
-
-
Rather Nicely Decentralized
-
Slim, generic core; most of the code organized in replacable plugins. Most plugins depend only on the core.
-
-
-
-
Index: trunk/doc-rnd/logo128.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/logo128.png
===================================================================
--- trunk/doc-rnd/logo128.png (revision 5606)
+++ trunk/doc-rnd/logo128.png (nonexistent)
Property changes on: trunk/doc-rnd/logo128.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/keys.html
===================================================================
--- trunk/doc-rnd/keys.html (revision 5606)
+++ trunk/doc-rnd/keys.html (nonexistent)
@@ -1,684 +0,0 @@
-
-
Copy selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); Mode(PasteBuffer)
-
Copy selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); Unselect(All); Mode(PasteBuffer)
-
ChangeDrill +5 mil ChangeDrillSize(Object,+5,mil)
-
ChangeDrill +5 mil ChangeDrillSize(Object,+5,mil)
-
-
s-alt-shift
-
ChangeDrill -5 mil ChangeDrillSize(Object,-5,mil)
-
ChangeDrill -5 mil ChangeDrillSize(Object,-5,mil)
-
-
s-ctrl
-
Save layout Save(Layout)
-
Save Layout Save(Layout)
-
-
s-ctrl-shift
-
Save layout as... Save(LayoutAs)
-
Save Layout As... Save(LayoutAs)
-
-
s-shift
-
ChangeSize -5 mil ChangeSize(Object,-5,mil)
-
ChangeSize -5 mil ChangeSize(Object,-5,mil)
-
-
space
-
Arrow Mode(Arrow)
-
Arrow Mode Mode(Arrow)
-
-
t
-
Text Tool scale +10 mil SetValue(TextScale,+10,mil)
-
Text Tool scale +10 mil SetValue(TextScale,+10,mil)
-
-
t-shift
-
Text Tool scale -10 mil SetValue(TextScale,-10,mil)
-
Text Tool scale -10 mil SetValue(TextScale,-10,mil)
-
-
tab
-
Flip up/down SwapSides(V)
-
Flip up/down SwapSides(V)
-
-
tab-ctrl
-
Spin 180° SwapSides(R)
-
Spin 180 degrees SwapSides(R)
-
-
tab-ctrl-shift
-
Swap Sides SwapSides()
-
Swap Sides SwapSides()
-
-
tab-shift
-
Flip left/right SwapSides(H)
-
Flip left/right SwapSides(H)
-
-
u
-
Undo last operation Undo()
-
Undo last operation Undo()
-
-
u-ctrl-shift
-
Clear undo-buffer Undo(ClearList)
-
Clear undo-buffer Undo(ClearList)
-
-
up
-
Step Up Cursor(Warp,0,1,grid)
-
Step Up Cursor(Warp,0,1,grid)
-
-
up-shift
-
Step +Up Cursor(Pan,0,50,view)
-
Step +Up Cursor(Pan,0,50,view)
-
-
v
-
Zoom Max Zoom()
-
Zoom Max Zoom()
-
-
v-alt
-
Via Tool drill +5 mil SetValue(ViaDrillingHole,+5,mil)
-
Via Tool drill +5 mil SetValue(ViaDrillingHole,+5,mil)
-
-
v-alt-shift
-
Via Tool drill -5 mil SetValue(ViaDrillingHole,-5,mil)
-
Via Tool drill -5 mil SetValue(ViaDrillingHole,-5,mil)
-
-
v-ctrl
-
Paste buffer to layout Mode(PasteBuffer)
-
Paste buffer to layout Mode(PasteBuffer)
-
-
v-ctrl-shift
-
Via Tool size -5 mil SetValue(ViaSize,-5,mil)
-
Via Tool size -5 mil SetValue(ViaSize,-5,mil)
-
-
v-shift
-
Via Tool size +5 mil SetValue(ViaSize,+5,mil)
-
Via Tool size +5 mil SetValue(ViaSize,+5,mil)
-
-
w
-
Add All Rats AddRats(AllRats)
-
Add All Rats AddRats(AllRats)
-
-
w-shift
-
AddRats Selected AddRats(SelectedRats)
-
AddRats Selected AddRats(SelectedRats)
-
-
x
-
-
Cycle object being dragged CycleDrag()
-
-
x-ctrl
-
Cut selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); RemoveSelected(); Mode(PasteBuffer)
-
Cut selection to buffer GetXY(Click to set the snap point for this buffer); PasteBuffer(Clear); PasteBuffer(AddSelected); RemoveSelected(); Mode(PasteBuffer)
-
-
x-shift
-
-
Swap nets on two selected pins net(swap)
-
-
y
-
Puller Puller()
-
Puller Puller()
-
-
y-shift
-
ChangeSizes to Route style ChangeSizes(Object,style,mil)
-
ChangeSizes to Route style ChangeSizes(Object,style,mil)
-
-
-A long standing misfeature of pcb (and pcb-rnd) has been that when dragging the
-end of connected traces, pcb chosen one of the traces "randomly". It often
-didn't pick the one the user wanted to move. The workaround was to move the
-one that pcb picked and then return and move the target trace then
-move the other trace back. This gets even more annoying if there are more than
-two objects connected in the given point: 3 traces and a via for example.
-
-The cycdrag patch addresses this issue by defining an action that can cycle
-through objects that could be dragged in the given point while the left mouse
-button is pressed. This lets the user explicitly select the one object to
-work on.
-
-This demo video
-demonstrates how it works with three lines and a via.
-
-
save/load and compatibility
-Not affected.
-
-
plans
-It does not work with the lesstif HID. It does not work with the rubber band
-mode.
-
-
-
Index: trunk/doc-rnd/features/mincut.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/mincut.png
===================================================================
--- trunk/doc-rnd/features/mincut.png (revision 5606)
+++ trunk/doc-rnd/features/mincut.png (nonexistent)
Property changes on: trunk/doc-rnd/features/mincut.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/nonetlist.html
===================================================================
--- trunk/doc-rnd/features/nonetlist.html (revision 5606)
+++ trunk/doc-rnd/features/nonetlist.html (nonexistent)
@@ -1,71 +0,0 @@
-
-
- pcb-rnd - [nonetlist]
-
-
-
-
-
-
-
-
-
-The [nonetlist] patch adds an element flag that makes PCB ignore the marked
-element when dealing with netlists. This means connecting a net to a pin of
-a nonetlist element will not cause a short. The refdes of a nonetlist
-part is drawn with color element-color-nonetlist (ElementColor_nonetlist
-in the source; default value #777777, grey).
-
-Uses of the nonetlist feature:
-
-
smd jumper: Combined with the [intconn] patch, this
- solves the "0-ohm 1206 jumper" problem: the element should be marked
- as nonetlist, with both pins set intconn(1) - this will result in a 2
- pad element, pads internally connected, that can be part of any one network
- without causing short and passing the DRC.
-
mechanical parts that should not show up on the schematics:
-
-
mounting hole elements: single pin holes with silk marking the head of the screw
-
chassis (often with mounting holes or keep-out areas)
-
logos in footprints (no poly support in footprint - yet?)
-
mechanical parts which do not have solderable pins (plastic spacers, extra connector shields)
-
"spare connectors", e.g. unused/disconnected DIP sockets, pin grids, or connectors in the corner of the PCB for prototyping (dev-board style)
-
-
-
-Preservation: gsch2pcb-rnd leaves nonetlist elements in the PCB.
-
save/load and compatibility
-This patch introduces a new element flag. The following example demonstrates
-a 1206 jumper footprint:
-
-Mainline PCB will load the design ignoring internal connections and nonetlist
-flag - this will cause shorts on all connected pins/pads and will break
-the connection.
-
-Mainline PCB doesn't save nonetlist and elements are embedded in the file -
-once the design is loaded and saved with mainline PCB, the flag is lost.
-After reloading the file in pcb-rnd, the element causes the same shorts
-as in mainline PCB.
-
-
plans
-No plans, the feature is complete.
-
-
Index: trunk/doc-rnd/features/square.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/square.png
===================================================================
--- trunk/doc-rnd/features/square.png (revision 5606)
+++ trunk/doc-rnd/features/square.png (nonexistent)
Property changes on: trunk/doc-rnd/features/square.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/unglib.html
===================================================================
--- trunk/doc-rnd/features/unglib.html (revision 5606)
+++ trunk/doc-rnd/features/unglib.html (nonexistent)
@@ -1,35 +0,0 @@
-
-
- pcb-rnd - [unglib]
-
-
-
-
-
-
-
-
-When (e.g.) routing 5mm power traces on a small grid, it's not always easy to hit the
-point where the trace ended (which is the center of the semicircle at the end of the
-line) to start the next line. If you have selected the line tool, finding the end of
-the line can become guesswork as the cursor doesn't change shape like it does with the
-select tool.
-I want my traces to consist of lines and arcs that are perfectly connected and I want
-to work as fast as possible.
-
-Attached is a small patch that
-
- - makes it possible to deactivate snapping to "some sensible point along a line".
- (that's what a comment in the code says). This snapping algorithm gets in the way
- sometimes so you have to slowly go over a line to find out where it really ends,
- bouncing back and forth between the points of the small grid, the end of the line
- and these "sensible points", which is wasting time. The command is
- "Display(ToggleSnapOffGridLine)". It is still activated by default to avoid
- violating POLA.
-
- - more importantly, introduces a new command called "Display(ToggleHighlightOnPoint)"
- that highlights all lines and arcs which have (end)points exactly on the position
- where the cross hair is currently snapped to. It therefore helps finding the end
- points of lines and arcs, but sometimes also shows redundant traces, traces that
- aren't perfectly connected to each other, traces that don't end directly on the
- center of a via but should, etc. It works with thin draw too and I tested it with
- gtk and lesstif.
-
-I use the second option mostly in conjunction with deactivating the first. Both commands
-have been added to the menu by means of (g)pcb-menu.res.in and are available as command
-line options as well.
-Caveats:
- - The HID API expects all HIDs to make a copy of the color string when setting a color.
- - The function that lightens up a color could be improved.
- - I used it for a while, but after porting it from my local fork, it probably needs
- more testing.
-
-
-The original code has a special setup for representing trees, C structures
-called LibraryMenu and LibraryEntry. This system can represent only a subset
-of trees: there is a root, a level consist of directories only and a next level,
-each directory consist of data nodes only. This has been enough for newlib,
-which strictly follows this model in the file system hierarchy. The lesstif
-HID also hardwired this model in the GUI.
-
-In pcb-rnd this has been replaced with a new struct type called library_t
-that can represent an arbitrary tree: directories and files within directories
-down to many levels.
-
-
-Many of the patches in this fork, and in possible future branches/forks
-may introduce new pin, pad or element flags. PCB loads and saves flags
-by converting the text representation to an in-memory binary format. Any
-flag not understood is lost.
-
-This patch adds a linked list of string flags, filled in with the unknown
-flags while loading a PCB. On save, these flags are appended to the normal
-flag list. This preserves all unknown flags (but not order of flags) in
-a load/save cycle.
-
-
save/load and compatibility
-This patch ensures compatibility in save/load cycles with flags introduced
-by later versions of mainline PCB or different branches/forks of PCB by
-not removing flags they introduced.
-
-
plans
-No plans - this feature is fully implemented.
-
-
Index: trunk/doc-rnd/features/grid_edge.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/grid_edge.png
===================================================================
--- trunk/doc-rnd/features/grid_edge.png (revision 5606)
+++ trunk/doc-rnd/features/grid_edge.png (nonexistent)
Property changes on: trunk/doc-rnd/features/grid_edge.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/pcblib.html
===================================================================
--- trunk/doc-rnd/features/pcblib.html (revision 5606)
+++ trunk/doc-rnd/features/pcblib.html (nonexistent)
@@ -1,74 +0,0 @@
-
-
- pcb-rnd - [pcblib]
-
-
-
-
-
-
-
-
pcb-rnd - the [pcblib] and [pcblib-param] and [fp_fs] patches
-
-
-The footprint library shipped with mainline pcb is cluttered with
-special puprose parts. I believe PCB encourages the user from
-an early stage to build his own library. Thus the purpose of
-the library shipped with PCB should be
-to provide a minimal collection of real essential footprints ...
-
-
... for the very beginning of the learning curve;
-
... and to be the core of the user's own library later.
-
-
-[pcblib] is a replacement of newlib/ and lib/ and the m4 macros with
-such an essential core library of static footprints ("file elements")
-and easier-to-use parametric footprints.
-
-Parts are sorted only in a few directories: smd, tru-hole, connector and
-parametric. I believe there are so many orthogonal properties of footpritns
-that there's no obvious hierarchy. Also, pcblib contains much fewer footpritns
-than newlib so it should be still easy to navigate.
-
-Parametric footprints are in a separate directory for now, even tho they
-would fit under smd, tru-hole or connector. The reason is purely historical
-and the layout may change in the future.
-
-
Example
-To the right: Footprint selection dialog on pcblib, with the smd directory
-open. Note how few smd parts are there. Still, smd/ is the most crowded
-subdirectory!
-
-
[fp_fs]
-As of vesion 1.0.10, the footprint list/search/load of footprints is a plugin.
-The original code that handles local file system footprint libraries (e.g.
-pcblib or newlib) is now a plugin. Altnerative plugins can be provided that work
-from databases or from the web. In extreme
-situations the file system based footprint plugin can even be disabled.
-
-
save/load and compatibility
-Not affected: elements are embedded in the PCB.
-
-
-
-Thanks to gpmi, pcb-rnd is scriptable in about 10 scripting languages (e.g.
-lua, awk, ruby, python, scheme, tcl). Scripts are integrated in pcb-rnd and
-have access to most of the internals. Scripts
-are able to:
-
-
register new actions
-
create new menus and submenus
-
execute existing actions
-
pop up simple dialog boxes (message, report, progress bar, file selection) -- check out the video
-
build and pop up custom dialog boxes (so called attribute dialogs)
-
search for objects (lines, arc, polys, vias, etc.) on the layout
-
change and move existing objects on the layout
-
create new objects on the layout
-
change "page" properties (dimensions of the board)
-
debug draw on the gui (slightly broken on gtk due to some gtk hid bugs)
-
-
-
-This feature has three options:
-
-
disabled: not compiled at all - when gpmi is not installed (no gpmi scripting in PCB)
-
buildin: compiled and linked in the executable - pcb-rnd always can load and run scripts
-
plugin: compiled as a loadable plugin - pcb-rnd can load and run scripts if the plugin is installed
-
-
-The original code was highlighting pins/pads only when a short came around
-after rats nest optimization. This was not very helpful on a complex board.
-There had been a long discussion on the mailing list about the best solutions.
-There were a few very good ideas, including:
-
-
manual tagging of objects (lines, polys, arcs, vias) with net and warn
- where two differently tagged net connects
-
automatic tagging based on "where it was connected first", then the same
- warning mechanism as above
-
trace history (using the undo buffer?) and go back until when it was
- not broken, check what exactly broke it
-
history combined with tagging
-
calculate minimal cut
-
-
-I choose minimal cut for my patch because it doesn't require tracing the
-full history or any manual administration of nets vs. objects (which I
-would find inevitable even with manual tagging - directly or indirectly
-the user needs to be able to change net tags).
-
-The minimal cut is the least amount of object whose removal would resolve
-the short. It is best demonstrated on an example:
-
-
-
-Removing all the marked lines/polys/vias would surely resolve the short
-(sometimes leaving rat lines behind). Minimal cut is better than randomly
-removing objects, tho: it guarantees that the minimal amount of objects
-are to be removed. On a complex board, this place is likely to be close
-to the place where the problem really is - much closer than the pins/pads.
-
-Since mincut can be expensive on large boards, the feature can be enabled
-per board (a new PCB flag) and can be disbaled globally (--enable-mincut 0
-when starting PCB).
-
-
save/load and compatibility
-New PCB flag enablemincut. Mainline pcb ignores this flag but does not
-preserve it.
-
-
-On small screen the overhead of the menu line, bottom status line and left
-layer selection bar is just too expensive. Since 1.1.2, the gtk hid can
-be switched between the usual setup and a so called "full screen mode"
-where most widgets are hidden, leaving much more screen space to the
-editor widget. There's a FullScreen() action that can set or toggle
-the state and a default key binding in gtk on the backslash ('\') to
-toggle it.
-
-
save/load and compatibility
-Not affected.
-
-
plans
-Make hiding various parts of the GUI configurable. No plans to implement
-it for the lesstif HID.
-
-
-
Index: trunk/doc-rnd/features/query.html
===================================================================
--- trunk/doc-rnd/features/query.html (revision 5606)
+++ trunk/doc-rnd/features/query.html (nonexistent)
@@ -1,42 +0,0 @@
-
-
- pcb-rnd - [query]
-
-
-
-
-
-
-
-
-Pcb-rnd features a flexible query language that can list (or select or find, etc.)
-objects mathcing an expression. The language handles different data types,
-including lists, provides means to iterate over objects and lists, supports
-the common logical and arithmetic operators.
-
-The query language is the engine behind the advanced search & select
-functionality. It is also the foundation of the programmable DRC.
-
-The query language is implemented as a core plugin.
-
-TODO: more details will come later, when the specification and implementation
-stabilizes.
-
-
pcb-rnd - the [cycdrag] patches, negative box select
-
-When a selection is made using drag&drop (box selection), depending
-on the direction the rule for object selection differ:
-
-
drag from top-left towards bottom-right (positive sized box):
- select objects that are fully contained in the box (original behaviour)
-
drag in any other direction (e.g. bottom-left to top-right, or
- bottom-right to top-left; negative sized box):
- select objects that are even partially within the box or merely touch
- the edge of the box
-
-
-The feature can be disabled using the editor/selection/disable_negative conf
-setting.
-
-It's possible to limit the feature so that only hirozintal-negative is
-considered negative size (i.e. only right-to-left dragging), using the
-editor/selection/symmetric_negative conf setting.
-
-
save/load and compatibility
-Not affected.
-
-
plans
-Work more on some rough corners of the negative direction: e.g. pads are
-handled as 0 width lines so the selection has to hit the center.
-
-
-
Index: trunk/doc-rnd/features/intconn1.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/intconn1.png
===================================================================
--- trunk/doc-rnd/features/intconn1.png (revision 5606)
+++ trunk/doc-rnd/features/intconn1.png (nonexistent)
Property changes on: trunk/doc-rnd/features/intconn1.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/intconn2.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/intconn2.png
===================================================================
--- trunk/doc-rnd/features/intconn2.png (revision 5606)
+++ trunk/doc-rnd/features/intconn2.png (nonexistent)
Property changes on: trunk/doc-rnd/features/intconn2.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/jumper_1206.fp
===================================================================
--- trunk/doc-rnd/features/jumper_1206.fp (revision 5606)
+++ trunk/doc-rnd/features/jumper_1206.fp (nonexistent)
@@ -1,7 +0,0 @@
-Element["nonetlist" "1206 jumper, 0 ohm" "" "1206" 0 0 -3150 -3150 0 100 ""]
-(
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "square,intconn(1)"]
- Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "square,intconn(1)"]
- ElementLine[-2362 -3740 2362 -3740 800]
- ElementLine[-2362 3740 2362 3740 800]
-)
Index: trunk/doc-rnd/features/intconn3.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/intconn3.png
===================================================================
--- trunk/doc-rnd/features/intconn3.png (revision 5606)
+++ trunk/doc-rnd/features/intconn3.png (nonexistent)
Property changes on: trunk/doc-rnd/features/intconn3.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/debian_list.html
===================================================================
--- trunk/doc-rnd/features/debian_list.html (revision 5606)
+++ trunk/doc-rnd/features/debian_list.html (nonexistent)
@@ -1,65 +0,0 @@
-
-
-
-
- pcb-rnd - Debian package list
-
-
-
-
-
-
-
-
pcb-rnd is load/save compatible with gEDA/PCB and kicad and offers various auxiliary import/export formats.
This metapackage installs the core and the most commonly used set of plugins.
-
pcb-rnd-core
This package contains the core program. Most functionality, including the GUI frontend, is in the corresponding plugin package.
-
pcb-rnd-gtk
pcb-rnd-core
This package contains the GTK+ user-interface for pcb-rnd.
-
pcb-rnd-lesstif
pcb-rnd-core
This package contains the Lesstif/Motif user-interface for pcb-rnd.
-
pcb-rnd-autocrop
pcb-rnd-core
This package provides the autocrop feature that can resize the board to minimum around all the existing objects.
-
pcb-rnd-autoplace
pcb-rnd-core
This package provides the autoplace feature used to place elements automatically and offers two different algorithms to do so.
-
pcb-rnd-autoroute
pcb-rnd-core
This package provides the classic gEDA/pcb autorouter.
-
pcb-rnd-diag
pcb-rnd-core
This package provides actions for debugging/diagnostic purposes. This feature may be needed for reporting bugs.
-
pcb-rnd-distalign
pcb-rnd-core
This package provides actions for arranging elements in an array.
-
pcb-rnd-distaligntext
pcb-rnd-core
This package provides actions for arranging text objects in an array.
-
pcb-rnd-djopt
pcb-rnd-core
This package provides actions to clean up (optimize) tracks. It is especially useful after autorouting.
-
pcb-rnd-gcode
pcb-rnd-core
This package allows exporting the design to gcode, useful for CNC milling.
-
pcb-rnd-gerber
pcb-rnd-core
This package allows exporting the design to gerber, accepted by most PCB fab houses.
-
pcb-rnd-lpr
pcb-rnd-core
This package allows printing directly from the GUI, using lpr.
-
pcb-rnd-nelma
pcb-rnd-core
This package allows exporting the design to nelma, for numerical capacitance calculation (via external tool)
-
pcb-rnd-png
pcb-rnd-core
This package allows exporting the design in various bitmap formats, including png and jpeg.
-
pcb-rnd-svg
pcb-rnd-core
This package allows exporting the design in SVG, the Scalable Vector Graphics format. It is useful for publishing the design on the web.
-
pcb-rnd-xy
pcb-rnd-core
This package allows exporting the design in XY, suitable for pick&place machines.
-
pcb-rnd-fontmode
pcb-rnd-core
This package lets the user to turn the GUI into a PCB font editor.
-
pcb-rnd-fp-wget
pcb-rnd-core
This package provides a wget based footprint accessor, which allows integrating web directories of footprints in the library. The only currently supported site is gedasymbols.org.
-
pcb-rnd-edif
pcb-rnd-core
This package allows pcb-rnd to import netlists in the EDIF format.
-
pcb-rnd-mincut
pcb-rnd-core
This package upgrades the indication of short circuits: instead of highlighting two random pins/pads, it tries to determine the minimal-cut that would resolve the short. In practice this means it makes a suggestion where to cut the networks to remove the short circuit.
-
pcb-rnd-oldactions
pcb-rnd-core
This package provides some old user actions. These are not used daily anymore, but some old actions scripts may still depend on them.
-
pcb-rnd-polycombine
pcb-rnd-core
This package provides actions to combine (merge) multiple polygons into a single, more complex polygon.
-
pcb-rnd-propedit
pcb-rnd-core
This package provides the property editor function for the GUI. The property editor collects all properties and attributes of all selected objects in a table and allows the user to change them.
-
pcb-rnd-puller
pcb-rnd-core
This package provides actions to "pull" tracks, minimizing their length.
-
pcb-rnd-query
pcb-rnd-core
This package provides the query language used in the advanced search on the GUI.
-
pcb-rnd-renumber
pcb-rnd-core
This package provides various actions to automatically renumber elements on the design. These actions change the refdes of some (or all) elements.
-
pcb-rnd-report
pcb-rnd-core
This package used to provide the report action that displays basic information about design objects. Unlike propedit, report does not allow the user to manipulate any of the data reported.
At the moment report is compiled into the core, this package is kept for compatibility and placeholder.
-
pcb-rnd-shand-cmd
pcb-rnd-core
This package provides 1..2 character long shorthands for the most commonly used core commands.
-
pcb-rnd-smartdisperse
pcb-rnd-core
This package implements a smart algorithm to disperse elements. It is useful after importing a new design from the schematics. It is an alternative to autplace.
-
pcb-rnd-stroke
pcb-rnd-core, pcb-rnd-gtk
This package implements mouse gestures using libstroke.
-
pcb-rnd-teardrops
pcb-rnd-core
This package embeds each pin in a teardrop drawn from multiple arcs. May be useful for toner-transfer boards.
-
pcb-rnd-vendordrill
pcb-rnd-core
This package provides vendor drill mapping and vendor specific design rule application.
-
pcb-rnd-kicad
pcb-rnd-core
This package allows pcb-rnd to load and save in kicad's s-expression based (new) file format.
-
pcb-rnd-gsch2pcb
This package provides the external tool gsch2pcb-rnd that can convert a gschem schematics to files that can be imported in pcb-rnd.
-
-
-
-In this effort I imported a set of old PCB plugins to be core plugins of
-pcb-rnd. This will make it easier to keep them up to date, to defeat
-the bitrot effect. The feature plugins that got imported so far:
-
-
autocrop
-
boardflip
-
distalign
-
distaligntext
-
jostle - doesn't work properly
-
polycombine
-
polystich - segfaults
-
teardrops
-
renumberblock - as part of the renumber plugin
-
smaprtdisperse
-
-
-The import/export plugins improted over the default set of the last official
-mainline release:
-
-
import_dsn - specctra importer - compiles, parser needs a full rewrite, it tries to read an s-expression line by line with fgets()
-
export_dsn - specctra exporter - compiles, produces valid-looking output - need tester to validate the output
-
-
-Our current Debian packaging reflects the modularity of pcb-rnd: it has
-most plugins in separate packages. The main package is called
-pcb-rnd-core: this provides the executable and the footprint library
-and the batch HID. The GUI HIDs are in pcb-rnd-gtk and
-pcb-rnd-lesstif - it's possible to install neither, either or both.
-When there are multiple HIDs installed, the user can select one by the
---gui command line parameter or by changing the GUI preference in the
-configuration (the default preference is gtk > lesstif > batch).
-
-The rest of the packages are features, importers and exporters, e.g.
-pcb-rnd-svg is the SVG exporter, pcb-rnd-query is the object
-query language needed for the advanced search.
-
-A metapackage called pcb-rnd is provided for convenience: it installs
-the packages for the most common, yet small setup, with the GTK HID.
-
-How to get the packages:
-
-
decide which packages you need; this package list may help
-
build them on your Debian box: use svn trunk, install debhelper and all the build dependencies of pcb-rnd and run "fakeroot debian/rules binary" in trunk (shorthand: "make deb")
-
-Back annotation was a long standing missing functionality. There has been
-different suggestions, including:
-
-
back annotation is not needed at all, the user can do it manually
-
pcb should generate a new netlist, the user should run diff on the netlists and manually edit the schematics
-
gschem should be able to load netlists emitted by PCB; or gnetlist could reverse-process such a netlist
-
-
-The current implementation allows pcb-rnd users to make deliberate pin
-swapping and footprint replacement. The changes can be saved in a
-"netlist patch" format. A modified gschem can load these and present them
-as search results pointing to parts of the schematics that need to be changed.
-There is a
-demo video about how this happens in practice.
-
-The modified gschem can be checked out from svn://repo.hu/geda-gaf-ba/trunk
-
-The underlying mechanism is versatile and potentially allows more changes
-to be back annotated. These are not yet accessible due to the lack of PCB
-actions and GUI.
-
-
Design decisions
-This devlog entry functions
-as a design decision document.
- Another entry is a summary
-on how the feature ended up in a private feature-fork of gschem.
-
-
save/load and compatibility
-Deliberate changes are tracked so that a new forward annotation from
-the old schematics won't break them. To do this, pcb-rnd saves a
-NetListPatch() section in the file. Mainline PCB can not handle this section.
-Compatibility, by use case:
-
-
1. No back annotation is made in pcb-rnd: the file stays compatible
-
2. Back annotation is made in pcb-rnd, then the changes are done on the schematics and a forward annotation is also done: the netlist patch in pcb-rnd becomes empty so the pcb file is again compatible with mainline pcb; this is called resolution of netlist patches
-
3. There are unresolved netlist patches saved in pcb-rnd and the user attempts to load the pcb file in mainline pcb: syntax error (but no data loss); solution: resolve the netlist patch as described in point 2.
-
4. Cheat for situation 3.: manually remove the NetListPatch() section from the save file. This way the back annotation info is lost, but mainline pcb can load the file again. This action is sort of "revert back annotation".
-
5. Any file saved by mainline PCB can be opened by pcb-rnd, back annotation does not affect that.
-
-
-
-The original code draws every grid point on screen, even the ones that are
-off the board. When the user zooms out with a dense grid, it can become too
-dense - the original code turns the grid off in this case.
-
-If the grid is very dense, on a large screen the software render may slow down.
-This is noticeable in pan and zoom mostly. The bottleneck is the gtk call
-that draws the grid points: if there are too many of them, it's slow.
-
-
-
New grid
-
-To overcome this problem, pcb-rnd offers configuration settings to limit
-the number of dots to be drawn. There are mainly two parallel approaches:
-using a local grid or draw less dots in a global grid. The
-old code defined only a global grid and did not have runtime settings for
-the properties of the grid.
-
-There's a new "Grid properties" submenu in the view menu in the default
-gtk hid menu file. Screenshots were taken with this menu teared-down to
-demonstrate the settings.
-
-
Global grid improvements
-
-The most trivial optimization is that grid points off the board are simply
-not drawn:
-
-
-
-Next, the compile-time configurable "minimum distance between grid points
-before it is too dense" setting is user configurable now. The default value
-can be changed in any of the usual
-configuration sources. However,
-when the configured density is reached while zooming out, there are two options.
-
-The first, default option is to do the same that the original code did: just
-hide the grid:
-
-
-
-An alternative is to use sparse global grid which means only
-every 2nd, 3rd, 4th, ... Nth grid point is drawn. The cursor still snaps
-to every real grid point, so the grid got sparse only on the display. Note
-how the line is drawn on invisible grid points:
-
-
-
-
Introduction of the local grid
-Another approach is to use a local grid. The grid helps finding whether
-existing objects are aligned or where the next move/click would end up.
-These are usually interesting only in a small range around the crosshair and
-less interesting on the other end of the board. Local grid draws the grid
-points only near the crosshair. Such local grid follows the crosshair
-everywhere:
-
-
-
-The user can configure or interactively set the radius in which the grid
-points are drawn:
-
-
-
-The radius is given in "number of grid points", thus the local grid yields
-a constant number of points that is independent of the actual grid size. When
-a local grid gets too dense, it is hidden - there's no sparse option, since
-local grids usually have too few points to make reasonable skips.
-
-
save/load and compatibility
-Not affected.
-
-
plans
-This feature is gtk-specific and is complete. There are no plans to
-implement this in the lesstif HID at the moment.
-
-
-
Index: trunk/doc-rnd/features/propedit.html
===================================================================
--- trunk/doc-rnd/features/propedit.html (revision 5606)
+++ trunk/doc-rnd/features/propedit.html (nonexistent)
@@ -1,65 +0,0 @@
-
-
- pcb-rnd - [propedit]
-
-
-
-
-
-
-
-
-Since 1.1.2, pcb-rnd core is able to attach user defined attributes
-(arbitrary textual key=value pairs) to any object. The original mainline
-pcb-rnd was forked from already supported attributes on some objects (e.g.
-board attributes, net attributes) but not on all. However, the user had
-very little access to the attributes - no GUI or action would handle them.
-
-Propedit introduces a property editor window in gtk that is able to
-edit attributes and core properties of all selected objects. Core properties
-include all hardwired properties of objects, such as geometry (e.g.
-trace width, hole diameter, clearance) or textual data (e.g. string of
-a text).
-
-
-
-Properties and attributes of the selected objects are collected in a
-sorted list - each row of the list is a property (starting with p/) or
-an attribute (starting with a/). For each row all values seen in the selection
-are also collected so that the following values can be presented on the list,
-per row:
-
-
the most common value
-
minimum value (for numeric value types)
-
maximum value (for numeric value types)
-
average value (for numeric value types)
-
-
-When the user clicks on a row, an edit box is activated and the value can
-be changed. A combo box lists all existing values for the given row, so
-it is easy to unify the value of a property or attribute among all selected
-objects to one of the existing values, but the user is also free to enter
-a new value.
-
-It is also possible to remove existing attributes or to add new attributes.
-
-
save/load and compatibility
-Attributes of most objects can not be saved in the original .pcb format.
-The propedit feature is most useful when used with the lihata board format.
-
-
plans
-Various improvements. Currently there's no plan to make this function available
-in the lesstif HID.
-
-
-
Index: trunk/doc-rnd/features/pcb-fp.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/pcb-fp.png
===================================================================
--- trunk/doc-rnd/features/pcb-fp.png (revision 5606)
+++ trunk/doc-rnd/features/pcb-fp.png (nonexistent)
Property changes on: trunk/doc-rnd/features/pcb-fp.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/res.html
===================================================================
--- trunk/doc-rnd/features/res.html (revision 5606)
+++ trunk/doc-rnd/features/res.html (nonexistent)
@@ -1,147 +0,0 @@
-
-
- pcb-rnd - [res]
-
-
-
-
-
-
-
-
-
-PCB used to have an own file format for describing resources (menu structure
-and hotkey bindings, vendor drill mapping). The resource format was generic
-enough to describe these things, but the syntax was somewhat wierd: mixed
-positional and named fields. More precisely, composite nodes could contain
-named and anonymous subnodes, and the meaning of anonymous subnodes depended
-on their position in the anon-subnode-list.
-
-The code that dealt with the in-memory representation of the resource tree
-was wierd and big chunks duplicated in the HIDs and vendor drill module. It
-was also hard to parse a resource file with external tools.
-
-Since version 1.0.10, pcb-rnd replaces resource files with
-lihata. Lihata is a small, generic
-purpose container format that can describe arbitrary trees. Just like resource
-file syntax, lihata is optimized for hand-editing: no need to use excess
-quoting or long boilerplate blocks.
-
-Liblihata also provides a lot of helper functions that made the code
-dealing with the menus and vendor drill resources much simpler and less
-redundant. Since the parser is small and external, and since there are
-external converter tools available, it is also easier to deal with the
-files outside of the pcb executable.
-
-
menu files
-There are pcb-menu-gtk.lht and pcb-menu-lesstif.lht. They are in trunk/src
-in the source tree and are instaslled in the SHAREDIR. Currently each GUI
-HID (lesstif, gtk) loads the corresponding menu file.
-
-
menu resource lihata structure
-The root of a menu resource file should be a ha: with the following
-children:
-
-
li:mouse for mouse button bindings
-
li:main_menu for describing the main menu
-
li:popups for describing the popup menus
-
-All children are optional, but recommended. Thus the file stucture, zoomed
-out, is:
-
-The mouse subtree may contain a li: for each mouse button action;
-the children of the list are further li: nodes for key modifiers, whose
-children are text nodes: actions executed in order.
-
-Buttons supported are: left, right, middle, up, down - the last two
-are for the scroll wheel. Modifier name should start with "press" or "release"
-optionally followed by modifier key suffixes separated with dashes, e.g.
-"press-alt-shift" means the given button is pressed while alt and shift
-were also pressed.
-
-The main menu is a list of menubar items that may host submenu items
-recursively. Each normal item is a hash with the following children:
-
-
li:submenu an ordered list of submenu nodes (should not have accel key or action)
-
tip tooltip text
-
action text or list of actions to execute when menu is selected
-
a a key description for an accelerator key (hotkey)
-
li:a a list of key descriptions for an accelerator keys (hotkeys); all keys will be bound to the menu and the first key is shown in the menu
-
-Special menu items are text nodes instead of hashes; they are:
-
-
starting with @, are dynamic, auto-generated items (e.g. layers; might be HID-dependent)
-
a singel dash: separator
-
-
-A key description is a text in the form of:
-
-
the name of the node is the visible name of the menu item
-
<key>keyname, e.g. "<key>k" for key K, or "<key>F10" for F10
-
modifier<key>keyname, e.g. "Alt-<key>K" for Alt+K
-
modifier-modifier<key>keyname, e.g. "Shift-Alt-<key>K" for Shift+Alt+K; modifiers are Alt, Shift and Ctrl; order does not matter, all three can be used together.
-
multikey sequence: multiple of the above, separated by semicolons (protected with {} for lihata, as the text contains semicolon); e.g. "{<key>f;<key>o}" means the user presses "f" then "o". Sequences can be a dozen stroke long and any segment may use modifiers
-
-
-An example menu item with submenus (can be a main menu or a submenu of
-another menu item):
-
-Each children is a hash that describes a popup menu. A popup menu behaves
-exactly like a menu item, it should have a submenu list. Popup windows will
-be popped up by executing an action with the name of the popup menu.
-
-
save/load and compatibility
-Not affected.
-
-
plans
-The resource file format conversion is done. There are other parts of the code
-that will probably get lihata instead of the current custom parsers, e.g.
-the preferences/settings file.
-
-
-
Index: trunk/doc-rnd/features/polygrid.html
===================================================================
--- trunk/doc-rnd/features/polygrid.html (revision 5606)
+++ trunk/doc-rnd/features/polygrid.html (nonexistent)
@@ -1,35 +0,0 @@
-
-
- pcb-rnd - [polygrid]
-
-
-
-
-
-
-
-
-
-Polygrid adds an option to the ps exporter to fill polygons with a grid
-of horizontal and vertical lines instead of full fill. When toner transfer
-is used or test prints are produced, the grid may save some toner.
-
-
-
-Since version 1.0.10, pcb-rnd implements a new footprint mechanism (see
-[fp_fs] and [library_t]).
-The new code allows footprint backend plugins to get library from anywhere.
-The [fp_wget] plugin is an implementation that:
-
-
downloads a library list from the web on startup into a local cache
-
downloads footprints from the web on-demand into a local cache
-
-
-This is all transparent, the user experience is that the remote library is
-like a read-only local library reachable from the library window.
-
-A web site used as a library should be able to:
-
-
generate a plain text list of all footprints available
-
return the raw footprint file by name
-
-
-The plugin uses external program wget to communicate on the web.
-
-
-
How to configure for gedasymbols.org
-Add wget@gedasymbols in the library search path (e.g. in preferences as library-newlib).
-
-
save/load and compatibility
-Not affected.
-
-
plans
-Better feedback on progress, explicit user requested refresh, refresh in
-the background.
-
-
-
Index: trunk/doc-rnd/features/grid_global_nosparse.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/grid_global_nosparse.png
===================================================================
--- trunk/doc-rnd/features/grid_global_nosparse.png (revision 5606)
+++ trunk/doc-rnd/features/grid_global_nosparse.png (nonexistent)
Property changes on: trunk/doc-rnd/features/grid_global_nosparse.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/square.html
===================================================================
--- trunk/doc-rnd/features/square.html (revision 5606)
+++ trunk/doc-rnd/features/square.html (nonexistent)
@@ -1,89 +0,0 @@
-
-
- pcb-rnd - [square]
-
-
-
-
-
-
-
-
-Most of my PCBs end up in toner transfer. There are a lot
-of tricks around prototyping at home. One of the problems I often
-face is small rings peeling off during rework (and rework tend to
-happen on the first prototypes). The solution for this is increasing
-ring size - which is not suitable if traces are passing between pins.
-Another solution is to increase the area of the pin:
-
-
square pin: while it makes the pin slightly larger still letting traces pass between pins, it's too symmetrical and can not use up extra room
-
DJ's teardrop plugin: this increases the area only toward the trace, whereas very often there's more room on the opposite side
-
manually add an extra poly around the pin; with multiple pins it's hard to get the polys separate
-
manually add a short extra track on the pin, width matching the size of the pin; this is very close, but increases workload when components are moved, layers are changed
-
-
-
-The patch takes an octagon pin and stretches points in various directions.
-There are 4 bits (for left, right, up and down) to indicate in which directions
-the stretch applies. Pressing 'q' on a pin cycles thru round pin, square pin,
-16 stretched octagons and the original octagon.
-
-The code is also patched to handle clearances, shorts and connections (find.c).
-
-Thermals are not fully working for funny shaped pins, but it has low priority:
-they still work fine for rounded and square pins and if there is a poly around
-the pin, I wouldn't use shaped pins anyway.
-
-
save/load and compatibility
-This patch introduces a new pin flag called shape(n), where n is an integer
-selecting the shape of the pin when the square flag is also set:
-
-Mainline PCB will load the design ignoring the custom shape and will use a
-square pin. As long a traces end in the center point of the pin, this
-should not break connections.
-
-Mainline PCB doesn't save shape() - once the design is loaded and saved with
-mainline PCB pin shape info is lost.
-
-
plans
-In the original code there are separate code paths for round, octagonal and
-square pins. The separation repeats for at least:
-
-
drawing the pin shape
-
calculating the clearance
-
checking whether things overlap or connect (pin vs pin, pin vs line, etc.)
-
autorouter
-
-In most cases a set of hardwired constants are written in the C code. A notable
-exception was the octagon pin draw function, that had x and y offsets in a const
-table for 8 points and a loop to create the poly (or line segments in thin draw).
-
-The [square] feature is a good base for cleaning up the code a bit and for
-moving toward a generic pin shape patch:
-
-
hardwired octagon calculations should be replaced to use the same x;y const offset table
-
the table should be replaced by a struct that describes length (number of points) - alternatively use POLYAREA
-
square pin should be renamed to polygon pin
-
octagon flag shall be removed - it should be a configuration of the x;y const table
-
square flag shall be removed - it should be a configuration
-
the only flag remaining should be shape(); if a pin is not shaped, it's round
-
the pin shape struct should have a field for compatibility - to mark the entry corresponding to the original square and octagon pins so PCB-rnd format can be converted to and from the mainline PCB format.
-
there should be a set of pin shapes in a default configuration table, including square and octagonal; these should be static
-
the PCB file format should be extended with an option to expand the pin shape table with custom shapes
-
UI: shapes could be imported (converted) from polys around vias
-
UI: since there may be a lot of pin shapes, a GUI selector alternative shall be offered while also keeping the cycle-thru 'q' key
-
-
-Footprints bring their own hole sizes, copper ring sizes and clearances.
-These parameters often depend on the manufacturing process, and such a value
-coming from a footprint may differ much from the values used on the board already.
-
-PCB has actions (and menus and hotkeys) to change sizes manually. In my practice,
-I try to stick to the sizes defined in my routing styles and try to avoid
-manually changing clearances or ring sizes. Still, the random values coming
-from various footprints should be changed.
-
-After many years of struggling with this, I realized the feature I need is
-a way to change object sizes to not a relative or absolute number but
-to the current routing style. The [tostyle] patch does exactly this.
-It implements the following new features:
-
-
change clearance size now works on elements: it changes the clearance of all pins/pads; this is the same as change drill has been working for a long time
-
size change actions normally take a value and a unit; if the value is not a number but text style, the value is copied from the currently active routing style
-
a new ChangeSizes() action that attempts to execute the other three change size actions with the same arguments and fails only if all of them failed; the three sizes are: main size, drill size, clearance size
-
a menu item and hotkey binding to key 'Shift+Y' (for routing stYle) that calls ChangeSizes() of the selected or current object(s) to resize them to the current routing style
-
-
-The new route style set works on:
-
-
lines and arcs: sets their line width and clearance
-
vias and individual pins: sets their ring dia, drill dia and clearance
-
individual pads: sets their clearance
-
elements: set all their pins and pads
-
-
-
Example
-GUI: select a routing style; hover above a line, a via, a pin/pad of an element
-or the silk of an element; press Shift+Y; undo if necessary.
-
-
-Mainline PCB core was coupled with the file format; the [io] patch set is
-an effort to decouple any file design I/O from core. The original file format
-(plain text .pcb and .fp) lives on as plugin called io_pcb.
-
-
-TODO
-
-
save/load and compatibility
-Not affected when io_pcb is used and .pcb or .fp files are loaded or saved.
-
-Using other io_* implementations will obviously result in files that are
-incompatible with mainline pcb (unless mainline pcb learns how to load those
-formats).
-
-
plans
-The project is still in an early phase.
-
-
-
Index: trunk/doc-rnd/features/index.html
===================================================================
--- trunk/doc-rnd/features/index.html (revision 5606)
+++ trunk/doc-rnd/features/index.html (nonexistent)
@@ -1,61 +0,0 @@
-
-
- pcb-rnd - features
-
-
-
-
-
-
-
-
-
-There are parts with internal connections (e.g. pin 2 and 4 of a SO8
-package are internally connected). Mainline PCB can not handle this,
-leaving the following options:
-
-
connect both pins to the net from the schematics - this works if all the internally connected pins are required to connect to copper (common with GND or power pins) but is very inconvenient for signal pins where only one of them needs to be connected
-
back-annotate which pin is connected - there's no easy back annotation
-
one pin connected, the other is closer to the next target; PCB doesn't understand that they are already connected internally; normally one shouldn't use the internal connection of a component instead of copper; except for the common practice to use 0 ohm SMD resistors for jumping wires
-
-
-The patch introduces a new pin flag intconn(g) which marks the pin
-to have internal connections in group g. If there
-are multiple pins using the same g value within a single element, they
-are internally connected. In other words, g is a group (or net name)
-within the element and pins can join to one of the numbered groups (or internal
-nets). The value of g shall be between 1 and 255, 0 means no internal
-connection (equivalent to the case when intconn(0) is omitted).
-
-When pin numbers are displayed (key 'd'), internal connection groups are
-written in square brackets, e.g. "2 [9]" means "pin 2, internally connected
-to group 9".
-
-Combined with the [nonetlist] patch, this
-solves the "0-ohm 1206 jumper" problem: the element should be marked
-as nonetlist, with both pins set intconn(1) - this will result in a 2
-pad element, pads internally connected, that can be part of any one network
-without causing short.
-
Example
-The first image depicts crossing traces, a common problem encountered when rats
-nesting a new layout from a netlist. One method to resolve such issues is to
-use a zero ohm jumper resistor that allows one signal trace to 'jump' across
-another.
-
-The second image shows the layout routing the nonconflicting rats and a open
-unrouted point where the rat would require one trace to cross another.
-
-In the third image a 1206 SMD footprint for a 0 Ohm 1206 resistor called J1 is
-placed with an intconn between the two pads which resolves the final rat line.
-
-
-
-
-
-
-
-
-
-
-
save/load and compatibility
-This patch introduces a new pin flag. In the following example
-pin 2 and 4 are connected internally as group 9, while pin 3
-does not have any internal connections:
-
-Mainline PCB will load the design ignoring internal connections -
-this may introduce new rats.
-
-Mainline PCB doesn't save intconn() and elements are embedded in the file -
-once the design is loaded and saved with mainline PCB, internal connection
-info is lost.
-
-
plans
-No plans - this feature is fully implemented. There is no plan for implementing
-a GUI, internal connections should be hand-edited into the element.
-
-
Index: trunk/doc-rnd/features/routings.html
===================================================================
--- trunk/doc-rnd/features/routings.html (revision 5606)
+++ trunk/doc-rnd/features/routings.html (nonexistent)
@@ -1,97 +0,0 @@
-
-
- pcb-rnd - routing style fixes
-
-
-
-
-
-
-
-
-In the original code there are a compile-time fixed number (4) of routing
-styles. This is often not enough for more complex designs. While in theory
-this limit can be raised, the resulting .pcb files will be incomatible with
-pcb compilations using a different number of styles.
-
-Pcb-rnd uses a dynamic vector for storing styles and allows any number
-of styles from 0 up to a very large value (2^31-1). There is no compile-time
-configurable limit. The number of default styles (and the actual style
-configuration) is coming from the template pcb file.
-
-Creating a new style in the Route Styles dialog is not "for this session only"
-anymore - styles are saved with the design.
-
-
Explicit custom style
-Pcb had 4 explicit styles and a hidden, implicit style. All drawing
-action uses the hidden style. When the user selects one of the explicit
-styles, its properties are copied into the implicit style. Any drawing
-action uses the implicit style, this it's sort of the "pen style".
-
-In mainline PCB the implicit (or pen) style is hidden. As long as it always
-matches one of the existing styles, the user doesn't even know about it.
-However, if there are objects that do not comform to any of the existing
-styles, it is possible to bump into this. For example:
-
-
draw a line using one of the existing styles
-
increase the width (with the 's' key) a few times - now the style of the line does not match any of the existing styles
-
use the SetSame() action over the line (hover the pointer over the line and press 'a') - it will try to set the style that corresponds to the line
-
since no style matches the line's, the radio button gets deselected - that's good
-
now click on the Route Style button - it will show the properties of the last selected route style, even tho it is not selected at the moment
-
-
-In contrast, pcb-rnd offers an explicit routing style called <custom>.
-If SetSame() is invoked on an object that doesn't match any of the existing styles,
-the <custom> style is selected:
-
-
no style marked on the radio button (just like in mainline)
-
the Route Style button opens with the <custom> style, with the values picked up from the object by SetSame
-
the user can change the values, which will affect the implicit pen style
-
this means the user can draw with the new settings, without having to create a permanent style
-
-
-In other words, it is now possible to use the implicit pen style as temporal
-style, to explicitly set a line width, via diameter before placing a few
-unusual lines or vias, without having to create a new style. It is also
-possible to pick up the style of such an unusual object later, without the
-GUI confusing it with any of the existing styles.
-
-
SetSame() bugs fixed
-A line does not have drill parameters. When mainline tries to pick up
-object properties for a line, it will pick thickness and clearance but
-will leave hole and ring diameters unchanged. This very often results in
-a mixed style: e.g. "signal" line properties picked up from a line while
-"power" hole/ring properties left over from the current style selection.
-Such a mixed pickup will result in the GUI get confused and not selecting any
-of the styles. The expected behaviour is to select the "signal" style if the
-line width/clearance matches the parameters of that style, and ignore the
-drill/ring parameters.
-
-The same mixup happens for picking up arc parameters, and a similar mixup
-for via parameters (a via doesn't have a line width).
-
-Pcb-rnd fixes this by searching for the matching style using only the parameters
-that the given object really had. This results in valid style selection
-the way the user may expect.
-
-
save/load and compatibility
-Saving a design with number of styles not equal to 4 may cause problems
-when loading with mainline. The rest of these features do not affect
-compatibility.
-
-
plans
-No plans - these features are fully implemented.
-
-
Index: trunk/doc-rnd/features/pcblib.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/features/pcblib.png
===================================================================
--- trunk/doc-rnd/features/pcblib.png (revision 5606)
+++ trunk/doc-rnd/features/pcblib.png (nonexistent)
Property changes on: trunk/doc-rnd/features/pcblib.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/features/dynstyle.html
===================================================================
--- trunk/doc-rnd/features/dynstyle.html (revision 5606)
+++ trunk/doc-rnd/features/dynstyle.html (nonexistent)
@@ -1,38 +0,0 @@
-
-
- pcb-rnd - [dynstyle]
-
-
-
-
-
-
-
-
-
-Pcb-rnd doesn't have a hardwired limit on number of routing styles
-anymore. Routing styles can be created on the fly and are saved to and loaded
-from .pcb files.
-
-There's no theoretical maximum explicitly set either. An implicit maximum
-exists and is sizeof(int) - should be at least 2^31 on most systems.
-
-
save/load and compatibility
-The first 4 styles are loaded and preserved by mainline. Styles above
-4 would probably be deleted in a mainline load-save cycle. The number 4
-is a constant value that can be changed if mainline is recompiled.
-
-
plans
-GUI HID representation of styles (especially in menus) need more testing.
-
-
Index: trunk/INSTALL
===================================================================
--- trunk/INSTALL (revision 5606)
+++ trunk/INSTALL (revision 5607)
@@ -15,7 +15,7 @@
(Note: it is important to cd to src to run pcb-rnd from source; src/pcb-rnd
won't work unless pcb-rnd is installed).
-If this doesn't work, please refer to doc-rnd/UNIX.txt or doc-rnd/mac.txt
+If this doesn't work, please refer to doc/UNIX.txt or doc-rnd/mac.txt
--
Index: trunk/Makefile
===================================================================
--- trunk/Makefile (revision 5606)
+++ trunk/Makefile (revision 5607)
@@ -8,11 +8,11 @@
cd src && make clean
cd util && make clean
cd pcblib && make clean
- cd doc-rnd && make clean
+ cd doc && make clean
distclean: FORCE
make clean ; true
- cd doc-rnd && make distclean
+ cd doc && make distclean
cd scconfig && make clean ; true
cd src_3rd/genlist && make clean ; true
cd src_3rd/genregex && make clean ; true
@@ -26,19 +26,19 @@
cd src && make install
cd util && make install
cd pcblib && make install
- cd doc-rnd && make install
+ cd doc && make install
linstall: FORCE
cd src && make linstall
cd util && make linstall
cd pcblib && make linstall
- cd doc-rnd && make linstall
+ cd doc && make linstall
uninstall: FORCE
cd src && make uninstall
cd util && make uninstall
cd pcblib && make uninstall
- cd doc-rnd && make uninstall
+ cd doc && make uninstall
deb: FORCE
fakeroot debian/rules clean
Index: trunk/src/Makefile.in
===================================================================
--- trunk/src/Makefile.in (revision 5606)
+++ trunk/src/Makefile.in (revision 5607)
@@ -290,7 +290,7 @@
AWK=@/host/fstools/awk@ ../scconfig/gen_core_lists.sh @/local/pcb/ACTION_REG_SRC@ > generated_lists.h
conf_core_fields.h: conf_core.h
- AWK=@/host/fstools/awk@ ../scconfig/gen_conf.sh ../doc-rnd/conf/tree < conf_core.h > conf_core_fields.h
+ AWK=@/host/fstools/awk@ ../scconfig/gen_conf.sh ../doc/conf/tree < conf_core.h > conf_core_fields.h
conf_internal.c: pcb-conf.lht
$(CQUOTE) -n conf_internal < pcb-conf.lht > conf_internal.c
Index: trunk/util/devhelpers/renamef.sh
===================================================================
--- trunk/util/devhelpers/renamef.sh (revision 5606)
+++ trunk/util/devhelpers/renamef.sh (revision 5607)
@@ -5,4 +5,4 @@
./rename.sh "s/\\([^a-zA-Z0-9_]\\)${1}[ \t]*[(]/\\1$2(/g"
./rename.sh "s/^${1}[ \t]*[(]/$2(/g"
-echo "$1 -> $2" >> doc-rnd/hacking/renames
+echo "$1 -> $2" >> doc/developer/renames
Index: trunk/util/devhelpers/renameo.sh
===================================================================
--- trunk/util/devhelpers/renameo.sh (revision 5606)
+++ trunk/util/devhelpers/renameo.sh (revision 5607)
@@ -6,4 +6,4 @@
s/\\([^a-zA-Z0-9_]\\)${1}$/\\1$2/g;
"
-echo "$1 -> $2" >> doc-rnd/hacking/renames
+echo "$1 -> $2" >> doc/developer/renames
-
-
-
-Legend:
-
Index: trunk/doc-rnd/hacking/obj_func_naming.txt
===================================================================
--- trunk/doc-rnd/hacking/obj_func_naming.txt (revision 5606)
+++ trunk/doc-rnd/hacking/obj_func_naming.txt (nonexistent)
@@ -1,83 +0,0 @@
-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-rnd/hacking/import.html
===================================================================
--- trunk/doc-rnd/hacking/import.html (revision 5606)
+++ trunk/doc-rnd/hacking/import.html (nonexistent)
@@ -1,64 +0,0 @@
-
-
-
'>>$(HTML)
-
-.pcb.png:
- $(PCB) -x png --dpi 300 $*.pcb
-
-out.pcb.out.png:
- $(PCB) -x png --dpi 300 $*.out.pcb
-
-clean:
- rm *.out.pcb *.png index.html 2>/dev/null; true
-
-
-
-
Index: trunk/doc-rnd/djopt/miter.pcb
===================================================================
--- trunk/doc-rnd/djopt/miter.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/miter.pcb (nonexistent)
@@ -1,80 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[500.0 0 0 1]
-Cursor[500 0 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-
-Attribute("PCB::grid::unit" "mil")
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 45000 15000 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 80000 47500 -4350 -5650 3 100 ""]
-(
- Pad[-1181 5905 1181 5905 5118 2000 5718 "1" "1" "square"]
- Pad[-1181 -5905 1181 -5905 5118 2000 5718 "2" "2" "square"]
- ElementLine [-3740 -2362 -3740 2362 800]
- ElementLine [3740 -2362 3740 2362 800]
-
- )
-Layer(1 "component")
-(
- Line[50905 15000 80000 15000 1000 4000 "clearline"]
- Line[80000 15000 80000 41595 1000 4000 "clearline"]
- Line[81181 41595 80000 41595 1000 4000 "clearline"]
- Line[80000 41595 78819 41595 1000 4000 "clearline"]
- Line[50905 16181 50905 15000 1000 4000 "clearline"]
- Line[50905 15000 50905 13819 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/viatrim.out.pcb
===================================================================
--- trunk/doc-rnd/djopt/viatrim.out.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/viatrim.out.pcb (nonexistent)
@@ -1,80 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[37500 10000 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-Via[60000 32500 7874 4000 0 3150 "" ""]
-Via[92500 32500 7874 4000 0 3150 "" ""]
-Via[75000 32500 7874 4000 0 3150 "" ""]
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 17500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 117500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-Layer(1 "component")
-(
- Line[23405 32500 60000 32500 1000 4000 "clearline"]
- Line[92500 32500 111595 32500 1000 4000 "clearline"]
- Line[60000 32500 60000 32500 1000 4000 "clearline"]
- Line[60000 32500 75000 32500 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
- Line[75000 32500 92500 32500 1000 4000 "clearline"]
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/vianudge.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/vianudge.png
===================================================================
--- trunk/doc-rnd/djopt/vianudge.png (revision 5606)
+++ trunk/doc-rnd/djopt/vianudge.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/vianudge.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/unjaggy.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/unjaggy.png
===================================================================
--- trunk/doc-rnd/djopt/unjaggy.png (revision 5606)
+++ trunk/doc-rnd/djopt/unjaggy.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/unjaggy.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/orthopull.pcb
===================================================================
--- trunk/doc-rnd/djopt/orthopull.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/orthopull.pcb (nonexistent)
@@ -1,98 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[47500 32500 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-Attribute("PCB::grid::unit" "mm")
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 52500 10000 4350 5650 1 100 ""]
-(
- Pad[-1181 -5905 1181 -5905 5118 2000 5718 "1" "1" "square"]
- Pad[-1181 5905 1181 5905 5118 2000 5718 "2" "2" "square"]
- ElementLine [3740 -2362 3740 2362 800]
- ElementLine [-3740 -2362 -3740 2362 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R103" "1206" 72500 10000 4350 5650 1 100 ""]
-(
- Pad[-1181 -5905 1181 -5905 5118 2000 5718 "1" "1" "square"]
- Pad[-1181 5905 1181 5905 5118 2000 5718 "2" "2" "square"]
- ElementLine [3740 -2362 3740 2362 800]
- ElementLine [-3740 -2362 -3740 2362 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R104" "1206" 62500 52500 -4350 -5650 3 100 ""]
-(
- Pad[-1181 5905 1181 5905 5118 2000 5718 "1" "1" "square"]
- Pad[-1181 -5905 1181 -5905 5118 2000 5718 "2" "2" "square"]
- ElementLine [-3740 -2362 -3740 2362 800]
- ElementLine [3740 -2362 3740 2362 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 35000 10000 -4350 -5650 3 100 ""]
-(
- Pad[-1181 5905 1181 5905 5118 2000 5718 "1" "1" "square"]
- Pad[-1181 -5905 1181 -5905 5118 2000 5718 "2" "2" "square"]
- ElementLine [-3740 -2362 -3740 2362 800]
- ElementLine [3740 -2362 3740 2362 800]
-
- )
-Layer(1 "component")
-(
- Line[52500 15905 52500 37500 1000 4000 "clearline"]
- Line[72500 15905 72500 37500 1000 4000 "clearline"]
- Line[62500 46595 62500 37500 1000 4000 "clearline"]
- Line[35000 37500 72500 37500 1000 4000 "clearline"]
- Line[35000 37500 35000 15905 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- Connect("R103-2")
- Connect("R104-2")
- )
-)
Index: trunk/doc-rnd/djopt/debumpify.out.pcb
===================================================================
--- trunk/doc-rnd/djopt/debumpify.out.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/debumpify.out.pcb (nonexistent)
@@ -1,88 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[0 5000 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 17500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 117500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-Layer(1 "component")
-(
- Line[23405 32500 30000 32500 1000 4000 "clearline"]
- Line[92500 32500 111595 32500 1000 4000 "clearline"]
- Line[30000 32500 30000 32500 1000 4000 "clearline"]
- Line[30000 32500 37500 32500 1000 4000 "clearline"]
- Line[37500 32500 37500 32500 1000 4000 "clearline"]
- Line[37500 32500 47500 32500 1000 4000 "clearline"]
- Line[47500 32500 57500 22500 1000 4000 "clearline"]
- Line[57500 22500 67500 22500 1000 4000 "clearline"]
- Line[67500 22500 77500 32500 1000 4000 "clearline"]
- Line[77500 32500 82500 32500 1000 4000 "clearline"]
- Line[82500 32500 85000 22500 1000 4000 "clearline"]
- Line[90000 22500 92500 32500 1000 4000 "clearline"]
- Line[85000 22500 90000 22500 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
- Text[30000 5000 0 105 "90" "clearline"]
- Text[60000 5000 0 105 "45" "clearline"]
- Text[82500 5000 0 105 "rand" "clearline"]
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/miter.txt
===================================================================
--- trunk/doc-rnd/djopt/miter.txt (revision 5606)
+++ trunk/doc-rnd/djopt/miter.txt (nonexistent)
@@ -1,2 +0,0 @@
-Replaces 90 degree corners with a pair of 45 degree corners, to reduce
-RF losses and trace length.
Index: trunk/doc-rnd/djopt/viatrim.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/viatrim.png
===================================================================
--- trunk/doc-rnd/djopt/viatrim.png (revision 5606)
+++ trunk/doc-rnd/djopt/viatrim.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/viatrim.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/vianudge.pcb
===================================================================
--- trunk/doc-rnd/djopt/vianudge.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/vianudge.pcb (nonexistent)
@@ -1,81 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[17500 22500 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-
-Attribute("PCB::grid::unit" "mm")
-Via[85000 50000 8661 4000 0 3937 "" ""]
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 57500 10000 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["onsolder" "Standard SMT resistor, capacitor etc" "R102" "1206" 10000 10000 5650 4350 2 100 "auto"]
-(
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "1" "1" "onsolder,square"]
- Pad[5905 -1181 5905 1181 5118 2000 5718 "2" "2" "onsolder,square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-Layer(1 "component")
-(
- Line[63405 10000 85000 10000 1000 4000 "clearline"]
- Line[85000 10000 85000 50000 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
- Line[15905 10000 30000 10000 2000 4000 "clearline"]
- Line[30000 10000 30000 27500 2000 4000 "clearline"]
- Line[30000 27500 85000 27500 2000 4000 "clearline"]
- Line[85000 50000 85000 27500 2000 4000 "clearline"]
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/orthopull.txt
===================================================================
--- trunk/doc-rnd/djopt/orthopull.txt (revision 5606)
+++ trunk/doc-rnd/djopt/orthopull.txt (nonexistent)
@@ -1,4 +0,0 @@
-Looks for chains of traces all going in one direction, with more
-traces orthogonal on one side than on the other. Moves the chain in
-that direction, causing a net reduction in trace length, possibly
-eliminating traces and/or corners.
Index: trunk/doc-rnd/djopt/debumpify.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/debumpify.png
===================================================================
--- trunk/doc-rnd/djopt/debumpify.png (revision 5606)
+++ trunk/doc-rnd/djopt/debumpify.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/debumpify.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/unjaggy.pcb
===================================================================
--- trunk/doc-rnd/djopt/unjaggy.pcb (revision 5606)
+++ trunk/doc-rnd/djopt/unjaggy.pcb (nonexistent)
@@ -1,81 +0,0 @@
-# release: pcb-rnd 1.0.7
-
-# To read pcb files, the pcb version (or the git source date) must be >= the file version
-FileVersion[20070407]
-
-PCB["" 140000 67500]
-
-Grid[2500.0 0 0 1]
-Cursor[12500 10000 0.000000]
-PolyArea[3100.006200]
-Thermal[0.500000]
-DRC[1200 900 1000 700 1500 1000]
-Flags("nameonpcb,clearnew,snappin")
-Groups("1,3,4,c:2,5,6,s:7:8")
-Styles["Signal,1000,7874,3150,2000:Power,2000,8661,3937,2000:Fat,8000,13780,4724,2500:Sig-tight,1000,6400,3150,1200"]
-
-
-Attribute("PCB::grid::unit" "mm")
-
-Element["" "Standard SMT resistor, capacitor etc" "R101" "1206" 17500 32500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-
-Element["" "Standard SMT resistor, capacitor etc" "R102" "1206" 65000 12500 -5650 4350 0 100 ""]
-(
- Pad[5905 -1181 5905 1181 5118 2000 5718 "1" "1" "square"]
- Pad[-5905 -1181 -5905 1181 5118 2000 5718 "2" "2" "square"]
- ElementLine [-2362 3740 2362 3740 800]
- ElementLine [-2362 -3740 2362 -3740 800]
-
- )
-Layer(1 "component")
-(
- Line[23405 32500 30000 32500 1000 4000 "clearline"]
- Line[30000 22500 37500 22500 1000 4000 "clearline"]
- Line[37500 22500 37500 15000 1000 4000 "clearline"]
- Line[30000 32500 30000 22500 1000 4000 "clearline"]
- Line[37500 15000 45000 15000 1000 4000 "clearline"]
- Line[45000 15000 45000 10000 1000 4000 "clearline"]
- Line[45000 10000 56595 10000 1000 4000 "clearline"]
-)
-Layer(2 "solder")
-(
-)
-Layer(3 "comp-GND")
-(
-)
-Layer(4 "comp-power")
-(
-)
-Layer(5 "sold-GND")
-(
-)
-Layer(6 "sold-power")
-(
-)
-Layer(7 "signal3")
-(
-)
-Layer(8 "outline")
-(
-)
-Layer(9 "silk")
-(
-)
-Layer(10 "silk")
-(
-)
-NetList()
-(
- Net("GND" "(unknown)")
- (
- Connect("R101-1")
- Connect("R102-2")
- )
-)
Index: trunk/doc-rnd/djopt/miter.out.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Index: trunk/doc-rnd/djopt/miter.out.png
===================================================================
--- trunk/doc-rnd/djopt/miter.out.png (revision 5606)
+++ trunk/doc-rnd/djopt/miter.out.png (nonexistent)
Property changes on: trunk/doc-rnd/djopt/miter.out.png
___________________________________________________________________
Deleted: svn:mime-type
## -1 +0,0 ##
-application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/djopt/index.html
===================================================================
--- trunk/doc-rnd/djopt/index.html (revision 5606)
+++ trunk/doc-rnd/djopt/index.html (nonexistent)
@@ -1,45 +0,0 @@
-
-
-
- 
-
- 
- 
-
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-