docs/wiki/geda-pcb_funding_sow.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html>
   4 <head>
   5   <title></title>
   6   <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
   7   <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
   8   <link rel="stylesheet" media="print" type="text/css" href="./print.css" />
   9
  10   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  11 </head>
  12 <body>
  13
  14
  15 <p>
  16 <strong>Statement of work:  Improving PCB&#039;s usability within the gEDA Suite framework</strong>
  17 </p>
  18
  19 <h2 class="sectionedit485"><a name="background_and_motivation" id="background_and_motivation">Background and motivation</a></h2>
  20 <div class="level2">
  21
  22 <p>
  23 The open-source layout tool <a href="http://pcb.gpleda.org/" class="urlextern" title="http://pcb.gpleda.org/"  rel="nofollow">PCB</a> has been a member of the gEDA Project for many
  24 years.  It is an essential part of the end-to-end design flow offered by the
  25 gEDA tool set.  That is, although gschem/gnetlist can (in principle) support
  26 many back-end PCB layout tools, the most advanced forward annotation tools
  27 have been developed for PCB, and the vast majority (if not all) of the gEDA
  28 Project&#039;s user base uses PCB as their layout tool.  PCB is a core part of the
  29 gEDA Project&#039;s software offerings.
  30 </p>
  31
  32 <p>
  33 For a variety of reasons, many electronics designers find PCB&#039;s user interface
  34 difficult to master.  Many tasks are best performed using PCB&#039;s internal
  35 command line (instead of menus or buttons), dropping to the unix shell, or
  36 even hand-editing design files using scripts or emacs.  Some specific
  37 shortcomings of PCB have been widely noted on the geda-* e-mail lists, along
  38 with reasonable solutions.   A list of the biggest issues includes:
  39
  40 </p>
  41 <ul>
  42 <li class="level1"><div class="li"> <strong>Forward annotation:</strong>  Difficulty forward annotating designs from gschem/gnetlist.  A separate command-line tool is used to carry the design from gschem to PCB.  This tool can produce design files out of synch with PCB.  Also, many electronics designers are unfamiliar with using the unix command line.</div>
  43 </li>
  44 </ul>
  45 <ul>
  46 <li class="level1"><div class="li"> <strong><acronym title="Graphical User Interface">GUI</acronym>:</strong>  PCB&#039;s <acronym title="Graphical User Interface">GUI</acronym> shows its age.  It has the following infelicitous properties:</div>
  47 <ul>
  48 <li class="level2"><div class="li"> It uses a mixture of noun/verb and verb/noun actions.  (Modern <acronym title="Graphical User Interface">GUI</acronym> programs are noun/verb only.)</div>
  49 </li>
  50 <li class="level2"><div class="li"> Incomplete menu/button coverage of possible editing actions.  For example, arbitrary rotation and component refdes renumbering are available only through the pop-up command entry window.</div>
  51 </li>
  52 <li class="level2"><div class="li"> There is a lack of <acronym title="Graphical User Interface">GUI</acronym> controls for exact, CAD-like editing. Examples for these desirable actions: Give the position of an object by typing its coordinates. Rotate an object by a given angle. Move objects by an exact amount. Do a multi copy of objects.</div>
  53 </li>
  54 <li class="level2"><div class="li"> Unlike many other graphical GUIs a dialog to edit properties of an object is missing in pcb. Properties to be edited might be layer, thickness, connected flag, polygon clearance, the net it belongs to, position, orientation, etc.</div>
  55 </li>
  56 <li class="level2"><div class="li"> Underlying the user interface, there is strong belief amongst PCB&#039;s developers that the supporting datastructures and methods are inadequate, and require upgrade as part of any <acronym title="Graphical User Interface">GUI</acronym> upgrade.</div>
  57 </li>
  58 </ul>
  59 </li>
  60 </ul>
  61 <ul>
  62 <li class="level1"><div class="li"> <strong>Footprint creation/editing:</strong>  Creating/editing footprints using PCB is difficult.  Most power users have created perl scripts to automate this process, but new users tend to be flummoxed by this approach.</div>
  63 </li>
  64 </ul>
  65 <ul>
  66 <li class="level1"><div class="li"> <strong>Layers and design objects:</strong>  Although PCB can handle any arbitrary number of metal layers, it does not fully support other design layers as independent objects.  For example, it lacks full support for common layout layers like: keepout, DRC, outline, etc.  Also, the concept of padstacks is missing from PCB.  Finally, PCB does not provide the full DRC functionality expected of a modern layout program.</div>
  67 </li>
  68 </ul>
  69 <ul>
  70 <li class="level1"><div class="li"> <strong>DRC:</strong>  The existing mechanism to find DRCs is clumsy.  Also, a separate DRC layer which may be turned on or off (typical of modern layout programs) is missing.</div>
  71 </li>
  72 </ul>
  73
  74 <p>
  75
  76 We envision that addressing the above problems will provide a significant,
  77 powerful benefit to PCB&#039;s usability within the larger framework of the gEDA
  78 toolkit.  Addressing the usability issues will bring the following specific
  79 benefits to the gEDA Project:
  80
  81 </p>
  82 <ul>
  83 <li class="level1"><div class="li"> <strong>Adoption:</strong> Making PCB easier to use will lead to greater uptake of the entire gEDA electronic design toolkit by practicing engineers, including those working in commercial organizations.</div>
  84 </li>
  85 </ul>
  86 <ul>
  87 <li class="level1"><div class="li"> <strong>Contribution:</strong>  More users implies more contributors.   In the context of the gEDA Project, this means not only software developers, but also people who will contribute schematic symbols, PCB footprints, utility scripts, and other collateral necessary to a thriving design environment.  (A strong focal point for contributors is – and will remain – the <a href="http://www.gedasymbols.org" class="urlextern" title="http://www.gedasymbols.org"  rel="nofollow">www.gedasymbols.org</a> website.)</div>
  88 </li>
  89 </ul>
  90 <ul>
  91 <li class="level1"><div class="li"> <strong>Support:</strong>  Engineers using the gEDA tools in a company context might be positioned to help organize funding for ongoing development of the gEDA Suite, thereby closing the circle from developers to users back to developers.  This would go a long way towards raising the gEDA Project above its current “advanced hobby hacker” status, a beneficial result for the entire gEDA ecosystem.</div>
  92 </li>
  93 </ul>
  94
  95 <p>
  96
  97 Therefore, the purpose of this document is to specify modifications to PCB
  98 which we hope will bring about a renaissance in the gEDA Project itself by
  99 making the critical tool PCB more accessible to the ordinary electronics
 100 engineer.
 101 </p>
 102
 103 </div>
 104 <!-- EDIT485 SECTION "Background and motivation" [86-4745] -->
 105 <h2 class="sectionedit486"><a name="statement_of_work" id="statement_of_work">Statement of work</a></h2>
 106 <div class="level2">
 107
 108 <p>
 109 This section provides descriptions of what work is desired in each area of PCB&#039;s functionality.  This is not a full specification;  it is assumed that the person chosen to perform this work is familiar enough with the concepts associated with PCB design and the internals of PCB that this statement of work provides sufficient guidance about what to do.
 110
 111 </p>
 112 <hr />
 113
 114 </div>
 115 <!-- EDIT486 SECTION "Statement of work" [4746-5135] -->
 116 <h3 class="sectionedit487"><a name="general_guidelines" id="general_guidelines">General guidelines</a></h3>
 117 <div class="level3">
 118
 119 </div>
 120
 121 <h4><a name="gtk_hid" id="gtk_hid">GTK HID</a></h4>
 122 <div class="level4">
 123
 124 <p>
 125 PCB supports several HIDs.  The HID is the interface layer which the user interacts with.  The two major HIDs provided for interactive use are based upon 1) the GTK <acronym title="Graphical User Interface">GUI</acronym> widget set, and 2) The X/Motif <acronym title="Graphical User Interface">GUI</acronym> widget set.  <strong>The work called out for this project shall be targeted at the GTK HID.</strong>  The reason for this is simple:  The rest of gEDA uses GTK.  A primary goal the renovation work in PCB is to more tightly bind PCB into the entire gEDA workflow.  More to the point:  the gEDA tool chain should present a more uniform interface to the user.  Users expect to see the same “look and feel” in all the tools they use.
 126 However, any changes made as part of this work shall not break any feature present in any other HID, including the Motif HID.
 127 </p>
 128
 129 </div>
 130
 131 <h4><a name="code_clarity" id="code_clarity">Code clarity</a></h4>
 132 <div class="level4">
 133
 134 <p>
 135 Many other changes are desirable in PCB.  However, they are outside the scope of this work.  The idea behind the changes specified here is that they create a launching point for other developers to come in afterward and continue improving PCB.  Therefore, <strong>the developer must strive to make his code clear and well commented.</strong>  Do not use hard to understand code tricks, obfuscating macros, or other devices which will hamper any follow-on work by other developers.
 136 </p>
 137
 138 </div>
 139
 140 <h4><a name="doxygen" id="doxygen">Doxygen</a></h4>
 141 <div class="level4">
 142
 143 <p>
 144 The developer should place Doxygen comments into the header of any new function he writes.  Fully doxygenating PCB is outside the scope of this project, but <strong>the developer should at least use doxygen for the changes he makes.</strong>
 145 </p>
 146
 147 </div>
 148
 149 <h4><a name="platforms" id="platforms">Platforms</a></h4>
 150 <div class="level4">
 151
 152 <p>
 153 The upgrades to PCB must work on the usual platforms supported by the gEDA Project.  Specifically:
 154 </p>
 155 <ul>
 156 <li class="level1"><div class="li"> Linux, BSD, Sun.</div>
 157 </li>
 158 <li class="level1"><div class="li"> GTK version 2.8 or later (consistent with gschem 1.5 head).</div>
 159 </li>
 160 </ul>
 161
 162 <p>
 163 Hooks for support on Windows systems are outside the scope of this project.  However, any Windows features present currently in PCB should not break as a result of these changes.
 164 </p>
 165
 166 </div>
 167
 168 <h4><a name="backwards_compatibility" id="backwards_compatibility">Backwards compatibility</a></h4>
 169 <div class="level4">
 170
 171 <p>
 172 <strong>Any changes made to PCB should not break the ability of PCB to import existing
 173 .pcb files.</strong>  It <strong>is</strong> allowed to break import of .new.pcb files (i.e. the output
 174 of gsch2pcb).
 175
 176 </p>
 177 <hr />
 178
 179 </div>
 180 <!-- EDIT487 SECTION "General guidelines" [5136-7257] -->
 181 <h3 class="sectionedit488"><a name="forward_annotation_upgrade" id="forward_annotation_upgrade">Forward annotation upgrade</a></h3>
 182 <div class="level3">
 183
 184 <p>
 185
 186 <a href="geda-pcb_funding_sow-fwdann_ideas.html" class="wikilink1" title="geda-pcb_funding_sow-fwdann_ideas.html">Ideas, commentary, and examples from users</a>
 187 </p>
 188
 189 </div>
 190
 191 <h4><a name="feature_description" id="feature_description">Feature description</a></h4>
 192 <div class="level4">
 193
 194 <p>
 195 The goal of forward annotation is to read the design information output from
 196 e.g. a netlister, and use it to import all information required into PCB,
 197 ready for use in creating or modifying a layout.  Reading the following
 198 information is a required part of creating a PCB layout:
 199
 200 </p>
 201 <ul>
 202 <li class="level1"><div class="li"> Footprints with associated refdeses and their associated layers (if assigned).</div>
 203 </li>
 204 </ul>
 205 <ul>
 206 <li class="level1"><div class="li"> Graphical elements (pads, tracks, polygons, holes, etc)  (usually imported from a previous design iteration).</div>
 207 </li>
 208 </ul>
 209 <ul>
 210 <li class="level1"><div class="li"> Electronic connectivity (netlist).</div>
 211 </li>
 212 </ul>
 213 <ul>
 214 <li class="level1"><div class="li"> Any global design information such as routing constraints.  (Currently unsupported by PCB).</div>
 215 </li>
 216 </ul>
 217
 218 <p>
 219
 220 The scheme currently used by PCB is to read a file – already in PCB format –
 221 containing the actual footprints embedded within it.  The netlist is read in
 222 using a separate step.
 223 </p>
 224
 225 <p>
 226 The new scheme would read a file containing a list of actions.  Each line in
 227 the file would correspond to a separate action.  The file would be generated
 228 by a forward annotation tool (e.g. gsch2pcb).  The actions would correspond to
 229 the atomic actions performed by PCB itself when it finds a footprint by
 230 searching its footprint library.
 231 </p>
 232
 233 <p>
 234 For example, one line in the forward annotation file might say
 235 “(load-element-data SOT-23 U6)”.  This would make PCB look for an SOT-23
 236 package in its footprint library (using PCB&#039;s $FOOTPRINT_PATH), place it in a
 237 waiting position on the PCB, and give it the refdes “U6”.  Another action
 238 might say “(add-line &lt;layer&gt; &lt;X1&gt; &lt;Y1&gt; &lt;X2&gt; &lt;Y2&gt; &lt;width&gt; &lt;flags&gt;)”, which
 239 would add a straight line segment onto layer &lt;layer&gt; from position (X1, Y1) to
 240 position (X2, Y2) having width &lt;width&gt; and flags &lt;flags&gt;.  (The flags would
 241 specify things like whether the line ends are round or square, along with the
 242 other properties of a line.)
 243 </p>
 244
 245 <p>
 246 Besides importing footprint and graphical information, the new PCB forward
 247 annotation facility should import the netlist at the same time as the rest of
 248 the layout information.  (This is currently a separate step, which is
 249 inconsistent with the goal of ease-of-use.)
 250 </p>
 251
 252 <p>
 253 Note that the above descriptions of the actions are meant to provide examples
 254 of how PCB should be modified.  The details of each action are to be
 255 determined by the developer and the architecture of PCB itself.
 256 </p>
 257
 258 </div>
 259
 260 <h4><a name="use_cases" id="use_cases">Use cases</a></h4>
 261 <div class="level4">
 262
 263 <p>
 264 Once the forward annotation changes are complete, the following use cases should apply:
 265 </p>
 266
 267 <p>
 268 <strong>New PCB</strong>
 269 </p>
 270 <ol>
 271 <li class="level1"><div class="li"> The user creates his design using gschem.  </div>
 272 </li>
 273 <li class="level1"><div class="li"> He creates a forward annotation file by running the .sch files through gsch2pcb, which creates a single .pfa (PCB forward annotation) file.</div>
 274 </li>
 275 <li class="level1"><div class="li"> The user starts PCB.</div>
 276 </li>
 277 <li class="level1"><div class="li"> He clicks “File → new PCB”.  A window pops up, providing a place to enter the new board&#039;s layer count and size.  The window may also provide a way to specify common board templates (PC-104, 3U Eurocard, etc.)</div>
 278 </li>
 279 <li class="level1"><div class="li"> The new board is shown in PCB&#039;s main window as a white area on a darker background (as currently implemented).</div>
 280 </li>
 281 <li class="level1"><div class="li"> The user clicks “File → Import forward annotation file”.</div>
 282 </li>
 283 <li class="level1"><div class="li"> A file selection window pops up.  The user clicks on his .pfa file and clicks OK.</div>
 284 </li>
 285 <li class="level1"><div class="li"> PCB reads each action in the forward annotation file, and does the corresponding thing.  </div>
 286 </li>
 287 <li class="level1"><div class="li"> The PCB netlist is also imported during this activity.  No separate netlist readin step is required.</div>
 288 </li>
 289 <li class="level1"><div class="li"> At the end of the file&#039;s read-in, the footprints should be present on the board (*not* in the paste buffer), ready to be disbursed and placed.</div>
 290 </li>
 291 </ol>
 292
 293 <p>
 294
 295 <strong>Existing PCB</strong>
 296 </p>
 297 <ol>
 298 <li class="level1"><div class="li"> The user has a pre-existing .pcb file for the design under consideration.  He makes changes to his design using e.g. gschem or gattrib.  </div>
 299 </li>
 300 <li class="level1"><div class="li"> The creates a forward annotation file by running the .sch files through gsch2pcb, which creates a single .pfa (PCB forward annotation) file.  </div>
 301 </li>
 302 <li class="level1"><div class="li"> The user starts PCB (or re-activates an existing PCB session running in its window).</div>
 303 </li>
 304 <li class="level1"><div class="li"> The user clicks “File → Import forward annotation file”.</div>
 305 </li>
 306 <li class="level1"><div class="li"> A file selection window pops up.  The user clicks on his .pfa file and clicks OK.</div>
 307 </li>
 308 <li class="level1"><div class="li"> PCB reads each action in the forward annotation file, and does the corresponding thing. Using the refdes, the importer looks to see if the component in the forward annotation file is already placed in PCB, and if so, it ignores the action.  </div>
 309 </li>
 310 <li class="level1"><div class="li"> The netlist is also read in and updated at this stage.  No separate netlist readin step is required.</div>
 311 </li>
 312 <li class="level1"><div class="li"> Once this action is complete, the user is ready to continue editing his board. </div>
 313 </li>
 314 </ol>
 315
 316 </div>
 317
 318 <h4><a name="other_ideas" id="other_ideas">Other Ideas</a></h4>
 319 <div class="level4">
 320 <ul>
 321 <li class="level1"><div class="li"> Besides a menu option, there should be a toolbar button to sync changes</div>
 322 </li>
 323 <li class="level1"><div class="li"> Alternately, a thread running a file change monitor can spot the new annotation file when it appears</div>
 324 </li>
 325 <li class="level1"><div class="li"> Finally, the project manager (gsch2pcb / xgsch2pcb / geda_manager) can invoke readin of a forward annotation file via IPC</div>
 326 </li>
 327 </ul>
 328
 329 </div>
 330
 331 <h4><a name="work_required" id="work_required">Work required</a></h4>
 332 <div class="level4">
 333
 334 <p>
 335 Some of the support for forward annotation already exists.  Specifically, many
 336 actions are already supported.  Therefore, this project involves:
 337 </p>
 338 <ol>
 339 <li class="level1"><div class="li"> Creating the missing actions required for full forward annotation.</div>
 340 </li>
 341 <li class="level1"><div class="li"> Creating a method for reading in an action script.</div>
 342 </li>
 343 <li class="level1"><div class="li"> Integrating the new script-based forward annotation into PCB&#039;s <acronym title="Graphical User Interface">GUI</acronym>.</div>
 344 </li>
 345 <li class="level1"><div class="li"> Testing and bug cleanup.</div>
 346 </li>
 347 </ol>
 348 <hr />
 349
 350 </div>
 351 <!-- EDIT488 SECTION "Forward annotation upgrade" [7258-12531] -->
 352 <h3 class="sectionedit489"><a name="gui_modernization" id="gui_modernization">GUI modernization</a></h3>
 353 <div class="level3">
 354
 355 <p>
 356
 357 <a href="geda-pcb_funding_sow-gui_ideas.html" class="wikilink1" title="geda-pcb_funding_sow-gui_ideas.html">Ideas, commentary, and examples from users</a>
 358 </p>
 359
 360 <p>
 361 The basic goal is to make the upgraded PCB behave exactly as an inexperienced
 362 user might expect, based upon his familiarity with modern <acronym title="Graphical User Interface">GUI</acronym>-based tools like
 363 OpenOffice.  This means:
 364
 365 </p>
 366 <ul>
 367 <li class="level1"><div class="li"> PCB should support all the “normal” keystrokes which have become defacto standards for <acronym title="Graphical User Interface">GUI</acronym> programs.  Examples include &lt;ctrl&gt;-c for copy, &lt;ctrl&gt;-x for delete, etc.  PCB may continue to support the old key strokes to maintain backward compatibility for those who are already experienced with the program, but in the event that one of PCB&#039;s current keystrokes conflicts with the “defacto standard”, the defacto standard shall be implemented.</div>
 368 </li>
 369 </ul>
 370 <ul>
 371 <li class="level1"><div class="li"> PCB should support all actions using “noun/verb” syntax.  Details of this upgrade are presented in the “actions” section below.</div>
 372 </li>
 373 </ul>
 374 <ul>
 375 <li class="level1"><div class="li"> PCB should support normal selection modes (i.e. ways to select an object for editing or modification).    Details of this upgrade are presented in the “selection methods” section below.</div>
 376 </li>
 377 </ul>
 378 <ul>
 379 <li class="level1"><div class="li"> PCB&#039;s internals should be upgraded to easily support enhanced menus and button bars.  This means upgraded callbacks and possibly also a resource file which specifies things like menu layout, menu options available, and keybindings.</div>
 380 </li>
 381 </ul>
 382
 383 <p>
 384
 385 If the descriptions in this specification are ambiguous or unclear, use the behaviors implemented in gschem as the preferred example.
 386 </p>
 387
 388 </div>
 389
 390 <h4><a name="actions" id="actions">Actions</a></h4>
 391 <div class="level4">
 392
 393 <p>
 394 The following actions should be modified to support a “noun/verb” actions,
 395 if they do not support it already.  Where possible, support for the current
 396 “verb/noun” actions should not be dropped to maintain compatibility for
 397 users who have learned the old actions.  However, if there is a conflict
 398 between the new noun/verb and the old verb/noun actions, the new noun/verb
 399 actions take presidence.
 400
 401 </p>
 402 <ul>
 403 <li class="level1"><div class="li"> <strong>select/delete</strong>  Using any of: menu item, &lt;ctrl&gt;-x.  Delete should move the deleted object(s) from the layout into the copy buffer, so the user may place them elsewhere with a subsequent action.  (NOTE:  The copy buffer should probably be implemented separately from the existing “element buffer”.)</div>
 404 </li>
 405 </ul>
 406 <ul>
 407 <li class="level1"><div class="li"> <strong>select/remove</strong>  Using any of menu item, &lt;del&gt;, character d.  Remove should permanently remove the selected item.</div>
 408 </li>
 409 </ul>
 410 <ul>
 411 <li class="level1"><div class="li"> <strong>select/move</strong>  Using: left mouse button down and drag.  Also:  Select, then use arrow keys to move the selected objects some small quantum of motion (perhaps the grid spacing) in the direction specified by the arrow.  </div>
 412 </li>
 413 </ul>
 414 <ul>
 415 <li class="level1"><div class="li"> <strong>select/copy</strong>  Using any of: menu item, copy button, character c. &lt;ctrl&gt;-c.  This should copy the selected items into the copy buffer so the user may place them elsewhere in a subsequent action.  (NOTE:  The copy buffer should probably be implemented separately from the existing “element buffer”.)</div>
 416 </li>
 417 </ul>
 418 <ul>
 419 <li class="level1"><div class="li"> <strong>paste</strong>  Using any of: menu item, paste button, &lt;ctrl&gt;-v.  This will bring the contents of the copy buffer into action at the cursor.  When the user clicks on the design, then the elements will be placed on the layout where the user clicks.  Refer to the behavior of gschem to see exactly how this should work.</div>
 420 </li>
 421 </ul>
 422 <ul>
 423 <li class="level1"><div class="li"> <strong>select/move selection to current layer</strong>  Using menu item, </div>
 424 </li>
 425 </ul>
 426 <ul>
 427 <li class="level1"><div class="li"> <strong>select/move object to opposite layer</strong> Using menu item, &lt;shift&gt;-c.</div>
 428 </li>
 429 </ul>
 430 <ul>
 431 <li class="level1"><div class="li"> <strong>select/report object properties</strong>  Using menu item or &lt;ctrl&gt;-r.</div>
 432 </li>
 433 </ul>
 434 <ul>
 435 <li class="level1"><div class="li"> <strong>select/edit object properties</strong>  Using menu item or double click on single object.  This is a new action.<br/>
 436 If the selected object is a graphical primitive (line, arc, etc), PCB will open up a window displaying the object properties in an editable window, allowing for the user to modify the object&#039;s properties.  For example double clicking on a Cu track should open up the edit window, showing the track&#039;s width, current layer, end type (round vs. square), and its beginning and end coordinates.<br/>
 437 If the selected object is a footprint, PCB will open up a window allowing the user to select a different footprint name.  Some type of footprint browsing window with previewing should be presented to the user for this.  The footprints should be found by looking through PCB&#039;s footprint search path.  Recommendation: steal the symbol browser window from gschem for this task.  (Question:  how to back annotate this info into the .sch files?)<br/>
 438 If the selected object is text, then PCB should open up the text edit dialog box, allow the user to edit his text, click OK, and the text on the layout should be updated.</div>
 439 </li>
 440 </ul>
 441 <ul>
 442 <li class="level1"><div class="li"> <strong>Select/rotate</strong>  Using menu item or &lt;ctrl&gt;-r.  This is a new window (the action already exists).  This will open a window asking the user to type in a rotation angle.  The user will type in the angle (in degrees), click OK, and the selected item will be rotated.  Ideally, the rotation would apply globally to a selected set of items; it is up to the developer to determine if this is feasible. If not, then rotate should apply to only one item.</div>
 443 </li>
 444 </ul>
 445
 446 </div>
 447
 448 <h4><a name="selection_modes" id="selection_modes">Selection modes</a></h4>
 449 <div class="level4">
 450
 451 <p>
 452 The following selection modes must be supported:
 453 </p>
 454 <ul>
 455 <li class="level1"><div class="li"> mouse click on single object.</div>
 456 </li>
 457 <li class="level1"><div class="li"> &lt;ctrl&gt;-click on multiple objects.  (Example:  &lt;ctrl&gt;-click this 1, &lt;ctrl&gt;-click this 2, &lt;ctrl&gt;-click this 3, etc.)</div>
 458 </li>
 459 <li class="level1"><div class="li"> Click and drag to select objects within a rectangular area.</div>
 460 </li>
 461 <li class="level1"><div class="li"> &lt;esc&gt; clears all selections</div>
 462 </li>
 463 <li class="level1"><div class="li"> &lt;ctrl&gt;-a selects all objects in the design.</div>
 464 </li>
 465 <li class="level1"><div class="li"> &lt;ctrl&gt;-A selects all connected objects.  (Question:  What is this selection mode useful for?)</div>
 466 </li>
 467 </ul>
 468
 469 </div>
 470
 471 <h4><a name="work_required1" id="work_required1">Work required</a></h4>
 472 <div class="level4">
 473
 474 <p>
 475 This project involves:
 476 </p>
 477 <ol>
 478 <li class="level1"><div class="li"> Refactoring and upgrade of program internals to support noun/verb actions.  </div>
 479 </li>
 480 <li class="level1"><div class="li"> Create new windows (e.g. object editor, move, rotate, etc.).  </div>
 481 </li>
 482 <li class="level1"><div class="li"> Refactoring and upgrade of program internals to support selection modes.</div>
 483 </li>
 484 <li class="level1"><div class="li"> Implementation of <acronym title="Graphical User Interface">GUI</acronym> resource file which is read in upon program start to configure user interface.</div>
 485 </li>
 486 <li class="level1"><div class="li"> <acronym title="Graphical User Interface">GUI</acronym> upgrade.  Specifically, hook up the callbacks to the menu items and buttons defined in the <acronym title="Graphical User Interface">GUI</acronym> resource file.</div>
 487 </li>
 488 <li class="level1"><div class="li"> Testing and bug cleanup.</div>
 489 </li>
 490 </ol>
 491 <hr />
 492
 493 </div>
 494 <!-- EDIT489 SECTION "GUI modernization" [12532-18467] -->
 495 <h3 class="sectionedit490"><a name="footprint_editor_implementation" id="footprint_editor_implementation">Footprint editor implementation</a></h3>
 496 <div class="level3">
 497
 498 <p>
 499 Incorporating a good footprint editor into PCB is a common request from users.
 500 It is important for PCB to clearly distinguish between editing a footprint and
 501 editing an entire PCB design.  Here are two possible methods to accomplish
 502 this:
 503 </p>
 504 <ol>
 505 <li class="level1"><div class="li"> Although it is not optimal, the symbol editing mode present in gschem provides a reference for how this might be implemented.  Specifically, editing a footprint may be implemented as a “mode”, in which the user drills down into the footprint, and is placed into a special mode of the standard PCB editing window which is reserved for editing footprints.  </div>
 506 </li>
 507 <li class="level1"><div class="li"> Another way to implement a footprint editor is to have a pop-up window with its own drawing pane along with editing widgets specialized for creating and modifying footprints.</div>
 508 </li>
 509 </ol>
 510
 511 <p>
 512 Optionally, features involving editing footprints via the buffer will be removed.  Alternately, retain the option allowing the user to draw in the main window, select, then invoke some menu option to convert the selection to a footprint.  This option may exist <strong>alongside</strong> the new footprint editor.
 513 </p>
 514
 515 </div>
 516
 517 <h4><a name="invocation" id="invocation">Invocation</a></h4>
 518 <div class="level4">
 519
 520 <p>
 521 There are two ways to invoke the footprint editor:
 522 </p>
 523 <ol>
 524 <li class="level1"><div class="li"> Create a new footprint.  In this case the user will have no object selected on the PCB drawing window.  He will then choose an option from the menu, like “tools → down footprint”.  This will place the user into the footprint editor, and the drawing area will be empty</div>
 525 </li>
 526 <li class="level2"><div class="li"> Edit an existing footprint.  In this case, the user will select a footprint present on the board by clicking on it.  Then he will select an option from the menu, like “tools → down footprint”.  This will place the user into the footprint editor, and the drawing area will hold a copy of the selected footprint, ready for editing.</div>
 527 </li>
 528 </ol>
 529
 530 <p>
 531
 532 As a third possibility, the user should be able to do “tools → create new footprint”, go into the editor, and then do “file → open” and select a footprint from the library to edit.
 533 </p>
 534
 535 <p>
 536 As a fourth possibility, allow a mode similar to gschem, where a library browser is used to select and place primitive objects.  That would save the user from needing to know where the library files are hidden.
 537 </p>
 538
 539 </div>
 540
 541 <h4><a name="editing" id="editing">Editing</a></h4>
 542 <div class="level4">
 543
 544 <p>
 545 The footprint editor should be a graphical drawing environment similar to that presented by PCB for layout editing.
 546
 547 </p>
 548 <ul>
 549 <li class="level1"><div class="li"> Buttons and menus.  The footprint editor should have all the same menus and buttons as are available from the PCB editor.  Those menu items and buttons which are not useful for footprint editing should be greyed out.</div>
 550 </li>
 551 </ul>
 552 <ul>
 553 <li class="level1"><div class="li"> Look and feel.  Once the user is placed in the footprint editor, the PCB window should change in some way to reflect that the user is in a different mode.  For example, the title bar must say “footprint mode”.  Also, the drawing field background color might be changed a little bit to emphasize the change in mode.</div>
 554 </li>
 555 </ul>
 556
 557 <p>
 558
 559 The design choice of which environment is better is left to the developer to decide based upon factors including input from the community, ease of implementation, etc.
 560 </p>
 561
 562 </div>
 563
 564 <h4><a name="saving" id="saving">Saving</a></h4>
 565 <div class="level4">
 566
 567 <p>
 568 Once the user has edited his footprint, he will want to save it out.  This is
 569 a problematic action, since it&#039;s not a good idea to allow the user to
 570 overwrite a footprint living in the footprint libraries.  Moreover, the user
 571 may not have write access to the library directories.
 572 </p>
 573
 574 <p>
 575 Therefore, when the user is done editing his footprint, there should be only
 576 one save action available under the file menu:  “file → save footprint as”.
 577 This will call up the file save dialog, which will default to sticking the
 578 footprint in the current working directory (or the last directory he saved a
 579 footprint into during this session).  The user will then be required to browse
 580 to his preferred save directory, and save the footprint there.
 581 </p>
 582
 583 </div>
 584
 585 <h4><a name="leaving" id="leaving">Leaving</a></h4>
 586 <div class="level4">
 587
 588 <p>
 589 Once the footprint editing session is done, the user may leave the editor and
 590 return to his main PCB editing session.  This may be accomplished using a menu
 591 item like “tools → up to layout”.  If any unsaved changes remain in the
 592 footprint, then the user should be prompted to either save or discard his
 593 changes before leaving the footprint editor.
 594 </p>
 595
 596 </div>
 597
 598 <h4><a name="updating_a_footprint_placed_on_the_board" id="updating_a_footprint_placed_on_the_board">Updating a footprint placed on the board</a></h4>
 599 <div class="level4">
 600
 601 <p>
 602 After editing a footprint and saving it out, the user will often want to
 603 update a footprint already present on the PCB.  Here is the preferred method
 604 (use case) to do this:
 605 </p>
 606 <ol>
 607 <li class="level1"><div class="li"> User selects footprint to update.</div>
 608 </li>
 609 <li class="level1"><div class="li"> From menu, user selects “tools → update footprint”.  A keystroke to start this action may also be provided.</div>
 610 </li>
 611 <li class="level1"><div class="li"> A pop-up window opens, giving the user the footprint browser (as described above).  The window will have has default footprint the name of the currently selected footprint.  </div>
 612 </li>
 613 <li class="level1"><div class="li"> The user will either accept the default footprint presented, or he may search for a different footprint.  When he is done, he will click OK.</div>
 614 </li>
 615 <li class="level1"><div class="li"> PCB will load the specified footprint from its library.  Note:  For this to work after editing a footprint, the user must place his local directory first on the footprint search path.</div>
 616 </li>
 617 <li class="level1"><div class="li"> PCB will then replace the old footprint on the board with the one pulled from the library.  The old footprint (currently written into the .pcb file) will go away, and the new one will take its place.</div>
 618 </li>
 619 </ol>
 620
 621 </div>
 622
 623 <h4><a name="work_required2" id="work_required2">Work required</a></h4>
 624 <div class="level4">
 625
 626 <p>
 627 This project involves:
 628 </p>
 629 <ol>
 630 <li class="level1"><div class="li"> Create internal structures and methods needed to support a separate footprint editor.</div>
 631 </li>
 632 <li class="level1"><div class="li"> Create footprint editing window (if the separate window approach is adopted).</div>
 633 </li>
 634 <li class="level1"><div class="li"> Integrate access to footprint editor into main PCB <acronym title="Graphical User Interface">GUI</acronym>.</div>
 635 </li>
 636 <li class="level1"><div class="li"> Testing and bug cleanup.</div>
 637 </li>
 638 </ol>
 639 <hr />
 640
 641 </div>
 642 <!-- EDIT490 SECTION "Footprint editor implementation" [18468-24056] -->
 643 <h3 class="sectionedit491"><a name="upgrade_of_layer_and_design_objects" id="upgrade_of_layer_and_design_objects">Upgrade of layer and design objects</a></h3>
 644 <div class="level3">
 645
 646 </div>
 647
 648 <h4><a name="feature_description1" id="feature_description1">Feature Description</a></h4>
 649 <div class="level4">
 650
 651 <p>
 652 Currently, PCB&#039;s internal data structures only “know” about metal and silk
 653 layers.  Other layers commonly used in PCB design are either missing (e.g. DRC
 654 layer, outline layer), or are simply derived from the metal layer (solder
 655 mask).  This task involves implementing full support for layers of arbitrary
 656 type and layer count.  Also, support for other design objects is part of this
 657 upgrade.  Specific features required are:
 658
 659 </p>
 660 <ul>
 661 <li class="level1"><div class="li"> Upgrade of existing datastructures to support layers of arbitrary type including: DRC, mechanical outline, annotation, solder mask, paste mask, plated through-hole, unplated through-hole, metal, silk.  The upgrade must also provide support for an arbitrary number of layers.  Also, allowing for per-layer clearance settings is an important feature for inclusion here.</div>
 662 </li>
 663 </ul>
 664 <ul>
 665 <li class="level1"><div class="li"> Implement window widget allowing for easy selection/configuration of layer stack-up.  Parameters to configure include:  layer count, layer type, layer polarity, layer visibility, layer color.  The window will also allow the user to re-order the layers (from front to back), and to add or subtract an arbitrary number of layers.  The layer window presented in “gerbv” is a reasonable example of what this window should support.</div>
 666 </li>
 667 </ul>
 668 <ul>
 669 <li class="level1"><div class="li"> Implement a new datastructure representing a pad stack.</div>
 670 </li>
 671 </ul>
 672 <ul>
 673 <li class="level1"><div class="li"> Implement a window widget allowing for easy editing of the pad stack&#039;s properties, including: metal annulus outer diameter (per layer), solder mask diameter (per layer), paste mask diameter (per layer), clearance width (per layer), hole diameter.</div>
 674 </li>
 675 </ul>
 676 <ul>
 677 <li class="level1"><div class="li"> Consider how the data-structures could allow support for blind or burried vias in the future.</div>
 678 </li>
 679 </ul>
 680
 681 </div>
 682
 683 <h4><a name="work_required3" id="work_required3">Work required</a></h4>
 684 <div class="level4">
 685
 686 <p>
 687 This project involves:
 688 </p>
 689 <ol>
 690 <li class="level1"><div class="li"> Upgrade internal structures and methods to enable full layer support.</div>
 691 </li>
 692 <li class="level1"><div class="li"> Create layer configuration window.</div>
 693 </li>
 694 <li class="level1"><div class="li"> Create internal datastructures and methods to support padstacks.</div>
 695 </li>
 696 <li class="level1"><div class="li"> Create padstack configuration window.</div>
 697 </li>
 698 <li class="level1"><div class="li"> Testing and bug cleanup.</div>
 699 </li>
 700 </ol>
 701 <hr />
 702
 703 </div>
 704 <!-- EDIT491 SECTION "Upgrade of layer and design objects" [24057-26082] -->
 705 <h3 class="sectionedit492"><a name="design_rule_checking_upgrade" id="design_rule_checking_upgrade">Design Rule Checking Upgrade</a></h3>
 706 <div class="level3">
 707
 708 </div>
 709
 710 <h4><a name="feature_description2" id="feature_description2">Feature Description</a></h4>
 711 <div class="level4">
 712
 713 <p>
 714 The goal of design rule checking (DRC) is to insure that a printed circuit
 715 board layout conforms to a set of design rules.  Design rules will consist of
 716 specifications like minimum copper line width, minimum copper spacing,
 717 etc. Generating a manufacturable PCB layout without DRC is tedious at best
 718 </p>
 719
 720 <p>
 721 The current PCB DRC steps through design rule violations one by one using a
 722 dialog box that reports the error, the coordinate position of the error and
 723 places the cursor at the error. Bouncing back and forth between the layout and
 724 the dialog box is time consuming. Knowing all of the errors prior to starting
 725 error correction is usually more productive.
 726 </p>
 727
 728 <p>
 729 A preferred method of reporting DRC violations would be to graphically
 730 indicate all errors on the layout. With this method all errors are quickly
 731 visible. DJ has suggested a layer for displaying DRC errors.  The user should
 732 be able to turn the layer visibility on and off.
 733 </p>
 734
 735 <p>
 736 A useful option for DRC would be to have it run periodically.  A proactive DRC
 737 should help novices avoid creating multiple similar errors.  Threaded operation,
 738 or a DRC which works in packets of time where the
 739 mainloop hits idle would be possibilities here. Both have their merits
 740 and draw-backs. If the operation is slow, we&#039;ll need some way to queue
 741 the work such that updates to the board in the mean time queue updates
 742 for new DRC checking.
 743 </p>
 744
 745 <p>
 746 Similarly, we&#039;d need to ensure that removing or
 747 changing objects on the board doesn&#039;t crash the DRC code - if it is
 748 running in a thread.
 749 </p>
 750
 751 </div>
 752
 753 <h4><a name="use_cases1" id="use_cases1">Use Cases</a></h4>
 754 <div class="level4">
 755
 756 <p>
 757 <strong>Manual DRC</strong>
 758 </p>
 759 <ol>
 760 <li class="level1"><div class="li"> The user runs DRC using either a hot-key or menu item. An unobtrusive DRC status indicator is displayed. Perhaps the phrase “DRC Check” in yellow text in the top bar.</div>
 761 </li>
 762 <li class="level1"><div class="li"> DRC violation marks are displayed on the DRC layer or on the PCB the layout.</div>
 763 </li>
 764 <li class="level1"><div class="li"> An unobtrusive DRC status indicator is displayed.  Perhaps the phrases “DRC PASS” in green text and “DRC FAIL” in red text in the top bar.</div>
 765 </li>
 766 <li class="level1"><div class="li"> If there are DRC failures the user can step to the next error manually or by using a hot-key. After changes are made the DRC can be run manually to verify the fix.</div>
 767 </li>
 768 </ol>
 769
 770 <p>
 771
 772 <strong>Automatic DRC</strong>
 773 </p>
 774 <ol>
 775 <li class="level1"><div class="li"> Using a menu item the user can set the appropriate time interval for running DRC. A default value is used if a new value is not set.</div>
 776 </li>
 777 <li class="level1"><div class="li"> The user enables automatic DRC mode.</div>
 778 </li>
 779 <li class="level1"><div class="li"> After the DRC idle period has elapsed DRC runs.  An unobtrusive DRC status indicator is displayed. Perhaps the phrase “DRC Check” in yellow text in the top bar.</div>
 780 </li>
 781 <li class="level1"><div class="li"> DRC violation marks are displayed on the DRC layer or on the PCB layout.</div>
 782 </li>
 783 <li class="level1"><div class="li"> An unobtrusive DRC status indicator is displayed.  Perhaps the phrase “DRC PASS” in green text and “DRC FAIL” in red text in the top bar.</div>
 784 </li>
 785 <li class="level1"><div class="li"> If there are DRC failures the user can step to the next error manually or by using a hot-key. After changes are made the DRC can be run manually to verify the fix.</div>
 786 </li>
 787 </ol>
 788
 789 </div>
 790
 791 <h4><a name="work_required4" id="work_required4">Work required</a></h4>
 792 <div class="level4">
 793
 794 <p>
 795 This project involves:
 796 </p>
 797 <ol>
 798 <li class="level1"><div class="li"> Implementation of DRC layer (part of work called out in “DRC Upgrade” section).</div>
 799 </li>
 800 <li class="level1"><div class="li"> Upgrade existing DRC checker with new DRC layer.</div>
 801 </li>
 802 <li class="level1"><div class="li"> Update <acronym title="Graphical User Interface">GUI</acronym> to use upgraded DRC checker.</div>
 803 </li>
 804 <li class="level1"><div class="li"> Testing and bug cleanup.</div>
 805 </li>
 806 </ol>
 807 <hr />
 808
 809 </div>
 810 <!-- EDIT492 SECTION "Design Rule Checking Upgrade" [26083-29268] -->
 811 <h3 class="sectionedit493"><a name="project_milestones_duration_and_budget_estimates" id="project_milestones_duration_and_budget_estimates">Project milestones, duration, and budget estimates</a></h3>
 812 <div class="level3">
 813
 814 <p>
 815 Although they are intertwined, the major focus areas are scoped independently
 816 here.  Ordinarily, a project manager would put a Gantt chart here, but that
 817 level of detail is probably too fine for the purposes of an open source
 818 project.  Therefore, I simply call out an estimated time required for each
 819 subtask.  The project duration times are SWAGs based upon my limited experience in estimating software projects.  They are based upon 8 hour work days (i.e. this work is performed
 820 as a full-time job) at a nominal billing rate of $50/hour.  <strong>It is up to the developer to
 821 validate these estimations and negotiate his own billing rate before he agrees to perform this work.</strong>
 822 </p>
 823
 824 </div>
 825
 826 <h4><a name="forward_annotation_upgrade1" id="forward_annotation_upgrade1">Forward annotation upgrade</a></h4>
 827 <div class="level4">
 828 <ol>
 829 <li class="level1"><div class="li"> Determine which actions remain to be scripted so that forward annotation of any board is possible using an action list.  (2 days).</div>
 830 </li>
 831 <li class="level1"><div class="li"> Define syntax for remaining actions, and document full syntax (2 days).  This document will be used to update gsch2pcb (outside the scope of this project).</div>
 832 </li>
 833 <li class="level1"><div class="li"> Write sample action scripts for testing purposes (1 day).</div>
 834 </li>
 835 <li class="level1"><div class="li"> Creating the missing actions required for full forward annotation (3 days).</div>
 836 </li>
 837 <li class="level1"><div class="li"> Creating a method for reading in an action script (2 days)</div>
 838 </li>
 839 <li class="level1"><div class="li"> Integrating the new script-based forward annotation into PCB&#039;s <acronym title="Graphical User Interface">GUI</acronym> (1 day)</div>
 840 </li>
 841 <li class="level1"><div class="li"> Testing and bug cleanup (5 days).</div>
 842 </li>
 843 </ol>
 844
 845 <p>
 846 Total duration:  16 days = 128 hours.
 847 Cost: $6400
 848 </p>
 849
 850 </div>
 851
 852 <h4><a name="gui_modernization1" id="gui_modernization1">GUI modernization</a></h4>
 853 <div class="level4">
 854 <ol>
 855 <li class="level1"><div class="li"> Refactoring and upgrade of program internals to support noun/verb actions (5 days)</div>
 856 </li>
 857 <li class="level1"><div class="li"> Create new windows (e.g. object editor, move, rotate, etc.) (5 days).  </div>
 858 </li>
 859 <li class="level1"><div class="li"> Refactoring and upgrade of program internals to support selection modes (5 days).</div>
 860 </li>
 861 <li class="level1"><div class="li"> Implementation of <acronym title="Graphical User Interface">GUI</acronym> resource file which is read in upon program start to configure user interface (3 days).</div>
 862 </li>
 863 <li class="level1"><div class="li"> <acronym title="Graphical User Interface">GUI</acronym> upgrade.  Specifically, hook up the callbacks to the menu items and buttons defined in the <acronym title="Graphical User Interface">GUI</acronym> resource file (3 days).</div>
 864 </li>
 865 <li class="level1"><div class="li"> Testing and bug cleanup (5 days).</div>
 866 </li>
 867 </ol>
 868
 869 <p>
 870 Total duration: 26 days = 208 hours
 871 Cost: $10400
 872 </p>
 873
 874 </div>
 875
 876 <h4><a name="footprint_editor_implementation1" id="footprint_editor_implementation1">Footprint editor implementation</a></h4>
 877 <div class="level4">
 878 <ol>
 879 <li class="level1"><div class="li"> Create internal structures and methods needed to support a separate footprint editor (4 days).</div>
 880 </li>
 881 <li class="level1"><div class="li"> Create footprint editing window (if the separate window approach is adopted) (3 days).</div>
 882 </li>
 883 <li class="level1"><div class="li"> Integrate access to footprint editor into main PCB <acronym title="Graphical User Interface">GUI</acronym> (2 days).</div>
 884 </li>
 885 <li class="level1"><div class="li"> Testing and bug cleanup (5 days).</div>
 886 </li>
 887 </ol>
 888
 889 <p>
 890 Total duration: 14 days = 112 hours.
 891 Cost: $5600
 892 </p>
 893
 894 </div>
 895
 896 <h4><a name="layer_design_object_upgrade" id="layer_design_object_upgrade">Layer/design object upgrade</a></h4>
 897 <div class="level4">
 898 <ol>
 899 <li class="level1"><div class="li"> Upgrade internal structures and methods to enable full layer support (5 days).</div>
 900 </li>
 901 <li class="level1"><div class="li"> Create layer configuration window (3 days).</div>
 902 </li>
 903 <li class="level1"><div class="li"> Create internal datastructures and methods to support padstacks (4 days).</div>
 904 </li>
 905 <li class="level1"><div class="li"> Create padstack configuration window (3 days).</div>
 906 </li>
 907 <li class="level1"><div class="li"> Testing and bug cleanup (5 days).</div>
 908 </li>
 909 </ol>
 910
 911 <p>
 912 Total duration: 20 days = 160 hours.
 913 Cost: $8000
 914 </p>
 915
 916 </div>
 917
 918 <h4><a name="design_rule_checking_upgrade1" id="design_rule_checking_upgrade1">Design Rule Checking Upgrade</a></h4>
 919 <div class="level4">
 920 <ol>
 921 <li class="level1"><div class="li"> Implementation of DRC layer (part of work called out in “DRC Upgrade” section) (0 days, assuming layer upgrade is complete).</div>
 922 </li>
 923 <li class="level1"><div class="li"> Upgrade existing DRC checker with new DRC layer (3 days).</div>
 924 </li>
 925 <li class="level1"><div class="li"> Update <acronym title="Graphical User Interface">GUI</acronym> to use upgraded DRC checker (2 days).</div>
 926 </li>
 927 <li class="level1"><div class="li"> Testing and bug cleanup (5 days).</div>
 928 </li>
 929 </ol>
 930
 931 <p>
 932 Total duration: 10 days = 80 hours.
 933 Cost: $4000
 934
 935 </p>
 936
 937 </div>
 938 <!-- EDIT493 SECTION "Project milestones, duration, and budget estimates" [29269-] --></body>
 939 </html>