Main	News	Doc & pool	Support	People	Events & timeline	pcb-rnd

pcb-rnd motivation

Phase 5: new data model (2018)

Mid 2018 the data model rewrite has mostly finished. The new model is capable of handling complex layer stackups, subcircuits, padstacks, slots. We are building a few long demanded features on top of the new infrastructure.

Phase 4: expansion, data model rewrite (2017)

Late 2016 and during 2017 there was a major expansion in number of developers, users and the amount of time spent on pcb-rnd. Our community is not tiny any more, and is very active: there is a lot of on-topic discussion going on on IRC every day, which result in bugs fixed and features implemented. Newcomers are intergated fast.

We started to rewrite the data model by slowly replacing elements with more generic subcircuits.

Phase 3: community requested features (2016)

There is a small, active, constructive community forming around pcb-rnd. Future directions will be mainly set by their need.

Phase 2: major cleanups (2015..2016)

• replaced the footprint mapping/loading code; instead of a hardwired m4 dependency, parametric (generated-on-the-fly) footprints can be written in any language
• replaced the default footprint library shipped with the software; the new library ships a small, well organized collection of essentials, omitting special/rarely used footprints
• got the code much more modular - a lot of core code got converted into plugins
• threw out the resource parser and file format (menu.res and friends) in favor of lihata; this removed a lot of code duplication and a strangely designed resource tree data structure I really hated; as a side effect the gtk hid has multi-stroke hotkeys
• replaced glib with a set of mini libs in core and most of the plugins; at the end only the gtk hid should depend on glib; this made the code easier to maintain and debug; a lot of checks are now compile-time (through the C type system) instead of runtime (glib lists)
• replaced the settings/rc/preferences system with a central, lihata based configuration system - long term hid attributes will be converted too

Plans for the future includes:

• turning most of the core code into a library for external tools to reuse
• extending the core to provide an infrastructure for composite objects handled by plugins
• support for saving and loading pcb and footprint files in the lihata format
• plans for a set of smallish features that can be implemented in a weekend or two each.

Phase 1: At the beginning... (2013..2014)

• PCB already knew 95% of everything I'd ever need years ago
• the remaining 5% was not on the TODO list of developers and generally no one shown much interest in getting patches for those
• meanwhile a lot of new features have been added, from which most I find totally useless:
  • dbus
  • gl - transparency makes even simple 2 sided boards unusable; slower than the classic version sw render on all my computers
  • preparation for a C++ transition
  • 3d support in core (I believe communication to 3d cad programs should be via exporter plugins)
• the official Debian package enables (requires, depends on) both dbus and gl
• DVCS - it almost always results in chaos, and has no benefit for such a small group of developers; there are posts from time to time on the mailing list about how to handle the chaos; my choice is to stick with a simple, centralized version control system
• DVCS always results in increased administration, which I hate to spend my time on - I'd rather invest the time in bugfixing, documentation or implementing new features
• it's nearly impossible to get small patches applied^1:
  • often no one has the time to revise and commit them
  • communication requires web2.0 (lp)
  • there are too many cycles of "please fix this and change that first"
  • with the chaos VCS, it's too likely that new feature patches would require ongoing maintenance while sitting in a "feature branch", to avoid that a large scale merge (or rebase, whatever) breaks it when it finally hits the official branch
  • there are too much pondering and too less prototyping; there are features that are being considered for years (for example back annotation, internal connections) with multiple concurrent ideas, but no code. Instead, I'd like to implement some code from the early phase of the idea, test it, and deprecate it if it didn't work out well.
  • I wouldn't even dream about getting larger patches in the official release
• no stable release for years; maintaining a set of patches (like pcb-gpmi) and porting them to new releases is too much hassle

• I stick with my fork and will use it on all my computers for all my designs
• Because of that, there's no emphasis on keeping the file formats compatible - breaking compatibility is not a goal either; as long as mainline doesn't change the format, pcb-rnd is about 98% compatible (the 2% is where pcb-rnd features are not supported by mainline)
• I won't actively seek ways to get my changes into the mainstream; I will keep on using my svn repo in a manner that (as a side effect) makes such merges easier, tho. If PCB developers decide to pick them up from svn and merge them in the official repo, it's fine (but I personally will keep using my fork anyway).
• Most probably I won't merge anything back from the mainstream to my fork - the past few years showed that it's unlikely there would be new features I'd need
• My plans for new features were:
  • pin shapes (a preliminary version was already implemented - as of 2017, it's obsolete because of padstacks)
  • 1206 jumpers without having to add them on the schematics/netlist (done: [intconn] and [nonetlist] are the pcb-rnd-side features for this)
  • merge pcb-gpmi; GPMI would be an optional addon, it'd probably stay a plugin, but there should not be a separate repo (done; meanwhile superseded by fungw scripting)

Footnotes:

• ^1: this may have changed lately and pcb developers are more open to newcomers; there seems to be a shortage of developers tho, which still makes it slow to get bigger patches through