(" strip(DB["lstate"]) ")" @@ -68,4 +116,13 @@ 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 + Index: trunk/doc-rnd/mods/index.html =================================================================== --- trunk/doc-rnd/mods/index.html (revision 1129) +++ trunk/doc-rnd/mods/index.html (revision 1130) @@ -1,80 +1,115 @@ +
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
+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 | After modularization: pcb-rnd version 1.0.8 + |
+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 | -604 + | ||||||||||||
| autoplace | 604 | works | buildin | Automatically place elements. - | |||||||||
| autoroute | -4172 + | ||||||||||||
| autoroute | 4172 | works | buildin | Automatically route selected or all rats. This is the original autorouter. - | |||||||||
| dbus | -438 + | ||||||||||||
| dbus | 438 | disabled
(TODO: needs scconfig support) | disabled | Remote control PCB using DBUS. - | |||||||||
| djopt | -2312 + | ||||||||||||
| djopt | 2312 | works | buildin | Various board optimization algorithms. - | |||||||||
| edif | -3575 + | ||||||||||||
| edif | 3575 | works | buildin | Import code for netlists in the EDIF format. - | |||||||||
| gpmi | -8881 + | ||||||||||||
| gpmi | 8881 | 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_sch | -252 + | ||||||||||||
| import_sch | 252 | works | buildin | Imports element and netlist data from the schematics (or some other source). - | |||||||||
| mincut | -884 + | ||||||||||||
| mincut | 884 | 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 | -50 + | ||||||||||||
| oldactions | 50 | works | disabled | Random collection of old/obsolete actions. Bell(): audible feedback; DumpLibrary(): print footprint library on stdout - | |||||||||
| puller | -1876 + | ||||||||||||
| puller | 1876 | works | buildin | Pull traces to minimize their length. - | |||||||||
| renumber | -212 + | ||||||||||||
| renumber | 212 | works | buildin | Renumber elements (renaming them) and generate a text file for back annotation. - | |||||||||
| stroke | -123 + | ||||||||||||
| stroke | 123 | partially works (doesn't work with lesstif; works with the gtk hid, but there's no zoom bindings) | buildin
(requires libstroke installed) | Gesture recognition with libstroke. - | |||||||||
| toporouter | -6159 + | ||||||||||||
| toporouter | 6159 | fails
(infinite loop in gts) | disabled | Automatically route selected or all rats using a topological algorithm. This is the new autorouter from 2009. - | |||||||||
| vendordrill | -564 + | ||||||||||||
| vendordrill | 564 | works | buildin | Vendor drill mapping.
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 (nonexistent)
+++ trunk/doc-rnd/mods/mods.png (revision 1130)
Property changes on: trunk/doc-rnd/mods/mods.png
___________________________________________________________________
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Index: trunk/doc-rnd/mods/pre.html
===================================================================
--- trunk/doc-rnd/mods/pre.html (revision 1129)
+++ trunk/doc-rnd/mods/pre.html (revision 1130)
@@ -1,5 +1,54 @@
+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: +
+I believe such modularization has benefits on multiple levels: +
Progress in charts+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. +
+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.
|