1. library window (basic functionality) If you use the window menu or the usual {w l}, you get a library window that will look very familiar for pcb-rnd users. Features that already work (the same as in pcb-rnd, unless mentioned otherwise): - navigating the tree - filter to help narrowing down a search - zoomable preview on the right when a symbol is selected - symbol copied to current paste buffer when symbol is selected - config node for library search paths is rc.library_search_paths - select something and press the refresh button - it will re-map the given subtree (you can use this if you have new files); you'll lose cursor - the subtree won't work yet, that still requires a real coding-intensive feature, will be part of a later test req 2. Stock symbol lib: static symbols I've drawn many symbols for the stock symbol library. Please browse the library window and see if they look good. Before you comment them, please read the rest of the email, there are important design decisions. The first one is minimalism: just like in case of pcb-rnd, and very very very much unlike in gschem/lepton/kicad, I decided to keep the stock symbol library shipped with the software small. The rationale is the scope and purpose of the library we ship: - sch-rnd and Ringdove in general are for advanced users, and experience shows advanced users build their own libraries, no matter what we ship - it's impossible to ship a "complete" lib so that users "have everything" and don't need to go and draw or download symbols from elsewhere; the more we ship, the bigger the number of symbols that the average user will never use, while our user can't save the hassle to deal with the missing ones - so instead of a big/complete/turn-key-ready lib, the real purpose of the lib we ship is to give a minimum set so a newcomer can experiment with the tool, drawing the first "blinking led" board without having to "first invent the universe" That said, please look at what we have and see if anything obvious is missing. If it's your favorit MCU, FPGA, "Split stator capacitor", "unshielded loop antenna" or other exotic thing, then it's missing intentionally. But if it's something really really common and essential for small and simple demo circuits, please let me know! 3. Stock symbol library: sizes While drawing those symbols, I had to tune the pool node with recommended symbol sizes, to meet the standard pin grid (4000) and make terminals easy to grab. Generally speaking everything got slightly bigger than my original "smallest readable size" idea, to meet the grid requirements. You can find the updated values in the pool node: http://repo.hu/cgi-bin/pool.cgi?project=sch-rnd-aux&cmd=show&node=sizes 4. transistor problem, polarization, portmap, devmap One of the many reasons for sch-rnd is learning from the design mistkes of the past efforts/implementations and trying to solve them. A very common problem is the transistor problem, for which cschem data model solution is portmap and devmap: http://repo.hu/projects/cschem/design/07_devmap_imp.html gschem/lepton don't have anything for this, in the name of freedom, so you either go with trillions of heavy symbols, or you write your own tool (symbol generator on the input or some sort of pin mapper that massages the netlist). I know at least 6 different implementations, it really looks like every gEDA user implements their own (I did too). The other end of the scale is what I've seen with some other formats (BXL) and EDA software, where there is One True Solution, a specific way symbol pins are mapped to footprint pins, hardwired in the executable of the EDA tool. In the cschem model I believe I figured how to combine the benefits of both approaches: provide 100% freedom _and_ also provide an optional, stock, "just works" solution without interfering if you decide to choose a different method. The whole thing depends on one thing, which is pretty much a policy of symbol design: when it matters, use terminal names, not pin numbers, then let whatever mapping mechanism you have deal with it. That simple. So if a part has equal terminals, like a resistor, I've just numbered them, because it doesn't really matter which is which, so you get 1 and 2. In case of a generic connector, just numbering the terminals is a fine choice. However, for any part with non-equal terminals, polarized or otherwise specialized ones, the lib strictly uses names. For diodes anode and cathode (A and K), for BJTs the usual B, C, E, etc. If we do it from start, and I mean not just in the standard lib, but in our user culture, we simply do not let the "transistor problem" happen in the first place, so we do not need to go and try to work it around afterwards. 5. Parametric symbols Just like pcb-rnd has parametric footprints, sch-rnd has parametric symbols. It makes sense to implement a symbol in parametric if there are virtually infinite number of variants may exist. For example we have connector(), that can generate connectors with any number of terminals. It does good job on single row connectord and dual row headers and spits out something usable for 3+ row ones. Doing this as parametric makes sense, because we don't need to draw (or pre-generate) a hundred different connectors and headers. However, doing a parametric for the dsub family wouldn't make much sense: while in theory they could be modular and we could have any amount of pins beteen a few and a lot, in practice there are only a few specific cases exist. Our other parametric symbol is switch(), which can generate all sort of switches, buttons and relays. We do not yet have the GUI parameter editing (I plan to do that later, needs coordination with pcb-rnd to avoid excess code duplication). Until that, you can refer to the documentation: http://www.repo.hu/projects/cschem/user/06_features/symbol_lib/parametric.html 6. generic power rail: the forge plugin Like gschem and many other EDA tools, we do offer attribute specified connections too: http://repo.hu/projects/cschem/design/02_data.html#des2:55 This is what we do in symbols like vcc or gnd: we have a single terminal, named 1, then we connect 1 to network by name Vcc (or GND). In case of a generic power symbol, we have a problem tho: - we either have to write the target network twice, once in a visible text object, and once in the portmap attribute with the ':' syntax - or we print the portmap attribute directly using dyntext, but then we have 1:VDDQ printed because that's the syntax the portmap requires Gschem/lepton went for a solution similar to the second (althoguh the syntax was the other way around there, VDDQ:1). New users often asked why's the ":1" suffix. It's easy to understand and is reasonable, but if there could be a better solution.... And there is! Because the cschem model makes the concrete/abstract model split explicit, and the compilation modular, we can have any kind of attribute transformation in between. A trivial solution to this problem is to invent a "rail" attribute where you enter VDDQ, print this "rail" attribute using dyntext, then have some attribute transformation that generates the VDDQ:1 thing on the portmap. This transformation could be implemented as a specialized plugin in C, for this one purpose. But that would be rather non-unixy (infinite number of specialized tools not usable for anything else than the one narrow thing the programmer had in mind). So instead I've introduced a generic attribute forge plugin that can be scripted in a trivial, regex based language. The script be stored in an attribute of the symbol. Documentation of the forge plugin (to be coded later, the coming month): http://repo.hu/projects/cschem/design/10_forge.html Explanation on how to use it in case of the generic rail: http://repo.hu/projects/cschem/design/10_forge_imp.html Stock library symbol that implements this idea and can be used for any rail (similar to "generic-power.sym" in gschem): rail.sym. Place it and edit the rail attribute (instead of some name or portmap or net* attribute). Notes: - the forge plugin is generic and can do a lot more - this whole complicated mechanism still follows a rule of simplicity: using the resulting rail symbol is easy to use and you need to know about all this complication only if you are designing a similar symbol (which would be very rare); so common case is easy, at the expense that the special case is more complex - ... and yet, the whole thing is optional; you can create a heavy symbol for your VDDQ, like we have for a few real common nets in the stock lib (e.g. Vcc); or you can go the gschem-way and print the portmap with dyntext so you get 1:VDDQ printed but you don't need to do any transformation.