[as of early 2019] The challange is how to give integration-prefering-users what they want without sacrificing our toolkit approach. For example gEDA failed badly on this in the "not providing what they want" way, while other packages (e.g. horizon, but even kicad for an extend) fail the other way (not keeping the toolkit approach). I think I have a design that could provide both, without any unwanted integration or special case coding. We need to do this fast, because the upset will fade, plus whoever wants to switch will switch to whatever is available today (e.g. kicad) and then we won't be able to convince them to switch once more. This is the design: 1. we have separate programs, for the Eagle user's in the first round the interesting ones are xschem, pcb-rnd and gerbv 2. we have an option, genxproj. The proof of concept video is: https://archive.org/details/genxproj-prealpha ; users who want to have integration can use genxproj, users who want to have a toolkit can ignore genxproj and user the command line, Makefiles or whatever glue they want 3. we need to upgrade our tools to do a few features that span across tools; integration-fan users don't care about programs, development teams, repositories, software projects, they care about how their EE project works in the ecosystem. We should target two features which are both relatively easy (sort of low hanging fruit) but both make a huge improvement in user experience for the integration-fans: A. GUI way of annotation As you see on the video, this already worked with pcb-rnd, an old git-version of gschem and stock gerbv. It does what our target audience wants: genxproj provides the arrow icons to move data from one software to another, from schematics through pcb to gerber. It also does what others want: it's toolkit, each software doing only its own task, they don't need to know about genxproj or anything beyond genxproj. B. cross-tool selection We don't have anything for this yet, but it wouldn't be too hard to do it. If the user selects an object (typically a network, component) in one tool, there should be a way to get it selected in the other tools. As a programmer this sounds like eye-candy. But as an (EE) user, this is really a big thing in practice. The preferred way how this all works for the integration-fan users: - they do not start individual tools but start genxproj with a glue script crafted for their specific workflow; for them, coralEDA is genxproj (... and the software hidden behind the scenes) - genxproj itself is a thin framework, it doesn't know anything about any of our coralEDA software or how to run or connect them; it knows how to run a GUI, how to start other programs, how to force-embed X applications in it, how to communicate with them and how to run a glue script that builds up the actual workflow (including the gui) from these building blocks - each application should deal with only its own business, they should not know or care about genxproj specifically or other applications in the flow - ... but each application should provide a generic API for remote control; this API is not specific to genxproj or to this one task, it's something any 'parent' process can use to drive the software What the remote control should be capable of: 1. [mandatory] read stdin, write stdout, while the gui is running; optimally this feature is controlled by a command line argument or some other volatile run-control mechanism, so genxproj or other host applications can easily request the program to start like this while it does not interfere with normal user's "start from console or desktop icon" applciation. A convention that may be worth following: pcb-rnd (and geda/pcb) calls the command-line option for this "--listen" 2. [mandatory] stdin commands for saving and loading files 3. [mandatory] stdin command for annotation/import/export 4. [mandatory] stdin command for selecting or unselecting objects; addressing the object is up to the software to specify; in case of xschem and pcb-rnd net name and refdes are trivial choices. In case of gerbv, I suggest using the location (line number or line:col) in the input file 5. [mandatory] stdout event for selection change (when objects are selected or unselected); the software doesn't need to worry about whether this should be a cross-app selection or not, that will be the duty of genxproj to decide 6. [optional] stream format: it's probably the best to define a simple, line/field based plain text protocol. If possible, make it either positional field based, or "command then arguments in key=value pairs". If possible, try to avoid s-experssion, json or other tree structured formats. Different tools can specify implement different formats, it can even be just the usual scripting language input (action script in pcb-rnd, tcl in xschem). If your software doesn't already have somethng and you'd prefer that, we can try to define a recommended format as part of the tEDAx effort. 7. [optional] it is recommended to accept more commands on stdin. The more the better. In an ideal world any operation the user can do on the GUI can be done through stdin (pcb-rnd is close to that). 8. [optional] it is recommended to print an stdout event for anything the user does. The more the better. (It may help future workflow glue scripts). 9. [optional] since event printing may generate a lot of traffic, event printing should be controlled (enabled) by a command on stdin (should be default off) 10. [optional] if the software prints anything else than events on the stdout, please help the glue script by prefixing event lines with a keyword the script can search for, so it's easier to ignore anything else.