| blob | f5fd1895e4defd1a59f39569151ec369d978fba0 |
3 <html>
4 <head>
10 </head>
11 <body>
16 <p>
17 As stated in <a href="libgeda3.html" class="wikilink1" title="libgeda3.html">libgeda3</a>, libgeda has some design problems that needs to be addressed. The structure described in this page is very different from the current libgeda structure and design, while hopefully can be flexible enough to be the basement of future developments.
18 </p>
20 </div>
22 <h1 id="descriptionoftheneedsinanelectricalcadsystem">Description of the needs in an Electrical CAD system</h1>
25 <p>
26 Schematics and PCB (or IC) designs are, by nature, a graphical representation of objects, with interconnections between them.
27 </p>
29 <p>
30 The basic primitives used in the graphical artwork are:
31 </p>
32 <ul>
34 </li>
36 </li>
38 </li>
40 </li>
42 </li>
44 </li>
45 </ul>
47 <p>
48 These basic shapes can have attributes modifying how they are drawn in the screen: dashed or dotted lines, filled or unfilled shapes,... , and can be grouped into a composed object (this object is drawn as a combination of one or more basic primitives). The graphical representation of a composed object is a symbol.
49 </p>
51 <p>
52 An electrical or electronic CAD must be able to draw components (composed objects) and interconnections between them. The interconnections is the key difference from other CAD packages, and are the basis of further engineering work, such as simulations or layouts. They are drawn as lines, but they are not only lines and therefore should be handled differently. The interconnection primitives are:
53 </p>
54 <ul>
55 <li class="level1"><div class="li"> Pin or ports: points of a composed object which can be used for interconnection, or connection points between pages.</div>
56 </li>
57 <li class="level1"><div class="li"> Nets: define the interconnections between pin or ports. It is usually drawn as a line.</div>
58 </li>
59 <li class="level1"><div class="li"> Junction: define the connection between crossing nets. It is usually drawn as a dot at the intersection of two crossing nets.</div>
60 </li>
61 <li class="level1"><div class="li"> Buses: group of nets. Trying to make things simple, they are drawn as a line, usually thicker than nets.</div>
62 </li>
63 <li class="level1"><div class="li"> Bus ripper: connects a net to a bus. It is needed because there should be a way to specify which net of the bus should be connected.</div>
64 </li>
65 </ul>
67 <p>
68 An electric circuit can be drawn in a page, but, as designs grow in complexity, it is usually divided into several interconnected pages, or is drawn as a hierarchy.
69 One common way is to draw a circuit defining some ports (where it is going to connect to other circuits), make a symbol for it, and include the symbol in other pages as it was a common composed object. So a design is composed of one or several pages, which can also include other page's symbols, and so on. Therefore, a design can be drawn as a hiearchy tree.
70 </p>
72 <p>
73 Finally, but not less important, every object described can have properties attached, describing the nature of the component, its attributes, or other representations (simulation models, graphical representation for PCB design,...).
74 </p>
76 </div>
81 <p>
82 Despite its title, this is not a section talking about Object Oriented Programming. :-)
83 </p>
85 <p>
86 It is a known fact that all schematics are graphical representations of components, interconnections and properties, organized as a plain or hierarchical tree.
87 </p>
89 <p>
90 One of the current issues with libgeda is that the schematic program itself, and hence the developers, should take care of all the drawing stuff associated with schematics. Plus, there are drawing transforms, like moving, rotating, mirroring, etc... This is very time consuming for the developer, and the results are not always the best.
91 </p>
93 <p>
94 This was fine at the moment when it was born, but technology is continuously evolving.
95 Today there are more advanced widgets that take care of all the object drawing, and lets the applications concentrate on what they should do. This kind of widgets are called "canvas".
96 </p>
98 <p>
99 Let's take a look at one of them: goocanvas. There are no screenshots, no official webpage, but don't be scared and look further. Download it and take a look at the documentation into the "doc" directory. You can also compile a demo, but you will need GTK 2.10 (for goocanvas version greater than 0.4), or GTK2.8 (goocanvas 0.4). I can tell you that the demo of the last version (0.8 at this moment) is quite impressive. If you have time, try it!. It is worth!.
100 </p>
102 <p>
103 Basically what it provides is:
104 </p>
105 <ul>
106 <li class="level1"><div class="li"> Already defined primitives: ellipse, image, path, polyline, rectangle, text, and even support for other GTK widges.</div>
107 </li>
109 </li>
110 <li class="level1"><div class="li"> Model/view implementation: several views of the same page is easily supported.</div>
111 </li>
112 <li class="level1"><div class="li"> Full hierarchy/nesting capability: there are no nesting limits.</div>
113 </li>
114 <li class="level1"><div class="li"> Uses cairo, already in GTK. This can be a drawback for some people, but if you have problems with cairo, it's likely you are going to have problems with the current gschem when GTK complete the transition into cairo.</div>
115 </li>
116 <li class="level1"><div class="li"> Built-in drawing transforms (rotating, scaling, moving,...).</div>
117 </li>
118 <li class="level1"><div class="li"> Full international text support without creating a new font. This is something true with some programs using a custom font: if you want it to support your language, you have to create the font for your special characters. (This is the case of the current gschem).</div>
119 </li>
121 </li>
122 <li class="level1"><div class="li"> Built-in object events: it can detect clicks on objects, for example.</div>
123 </li>
125 </li>
126 </ul>
128 <p>
129 The advantage is clear: all the basic drawing primitives and operations are already done.
130 </p>
132 <p>
133 So the proposal is to base all the geda objects on the objects supplied by the canvas (note that every canvas you find is going to provide its own object classes, so this is a canvas based generic design.
134 </p>
136 </div>
141 <p>
142 The geda object definition could be something as simple as:
143 </p>
146 GList <span class="sy0">*</span>views<span class="sy0">;</span> <span class="coMULTI">/* List of pointers to GooCanvasItems
147 This could solve the problem about heterogeneus parts:
148 We can store as many graphical representations of they object as we want */</span>
152
155 GooCanvasItem group<span class="sy0">;</span> <span class="coMULTI">/* There is also an item for groups of objects */</span>
158 <p>
159 There is no need to store graphic attributes in GedaObject. If the position is needed, since the canvas item can be queried.
160 Some special definition for properties is needed (they shouldn't be handled as just text):
161 </p>
162 <pre class="code C"><span class="kw4">struct</span> GedaObjectProperty <span class="br0">{</span>
168 <p>
169 and another one for connectivity items:
170 </p>
171 <pre class="code C"><span class="kw4">struct</span> GedaObjectPort <span class="br0">{</span>
176
182
183 <span class="kw4">struct</span> GedaObjectNet <span class="br0">{</span> <span class="coMULTI">/* or bus, or bus ripper */</span>
189 <p>
190 Everything else can be done attaching properties to the defined objects. For example, a page is just as any other GedaObject, where the view item points to a GedaObjectGroup.
191 Notice that having multiple views for a page could be just like a page having multiple pages (at the same hierarchy level).
192 </p>
194 <p>
195 No object naming is required, although it is already supported by default: you can add a GedaProperty to any other object (it will become part of the object).
196 </p>
198 <p>
199 Example: a 7400 symbol, with a footprint attribute "DIP-16", and reference designator "U1" would look as:
200 </p>
202 |- views
203 | |- GedaObjectGroup
204 | | |- GedaObjectGroup /* the graphic representation */
207 v v </pre>
209 </div>
214 <p>
215 There is no easy and direct way to get this structure into the current codebase. However, the current codebase can be adapted progressively to use this structure.
216 </p>
218 <p>
219 All canvas specific code can be hidden by a common interface or a runtime plugin, so a possible change of the used canvas could be easy.
220 </p>
222 </div>
227 <p>
228 Leave your comment here!
229 </p>
231 <p>
232 [Peter C] {
233 </p>
235 <p>
236 Hi. I think a canvas could be the right way to go with gschem, however we should design libgeda structures to represent the underlying circuit, design, and CAD / graphics concepts involved. I'd hope we can avoid linking any canvas or UI specific structures into libgeda. In a sense, part of what libgeda's does is define canvas independent data-structures and manipulation functions for for the graphic objects on a schematic page.
237 </p>
239 <p>
240 We can write a wrapper between libgeda and the canvas for actual rendering. It looks (superficially) that this is possible with goocanvas. The two basic cases are "compound" gEDA objects which map to groups of other objects (like complex objects, the current font implementation etc.), and gEDA objects which map to primitives like lines and arcs.
241 </p>
243 <p>
244 I think some of the important design decisions to make now involve defining the API for object / design database manipulation, and what signals and hooks we might expose to other code. I'd start by considering starting with basic "translate, rotate, mirror, ...." operations like libgeda has now, and then explore signals notifying that an object has changed.
245 </p>
247 <p>
248 }
249 </p>
251 </div>
252 </body>
253 </html>