# pcb-rnd devlog

## cschem

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 in order 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 (through 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 development, 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
- q7. attribute conventions