> Is it not possible to make a top level program that launches the > different programs (gschem, pcb, simtools, .....)?
Yes. In fact, this has been done. However, it serves to collect the various files that make up a design, not the information *in* the design. The underlying tools still deal with the same files and data as they would without a GUI, and the underying tools still force the user to jump from tool to tool to get various tasks done. What I think users want is to have the underlying tools be more aware of the other sources of data in the design, and each other, so that the GUIs appear to be more integrated despite being individual tools and datasets underneath. This may require some high-level "these are the files in your design" also, but it's a slightly different problem to solve. But an even different is the problem of what *design* data goes in which file. This part is not backwards compatible, because we'd want to move data out of the other files (sch, pcb, whatever) into a new container. Consider: if we have N steps in our "flow", we currently have N files and N tools, each of which deals with their one data file, with converters between them. But what if each tool could interact with the data files from step N-1 and N+1 also? In the past, this has meant that gschem knew about pcb's file format, and pcb knew about gschem's (via gnetlist). But a new container between schematic and pcb (for example) would allow these two steps to have a common spot to store common data, without either needing to know about each other's private data. Now add to that, plug-ins for each tool that know how to directly communicate with other running tools related to the design (gschem, pcb, gerbv, icarus). Now, each tool has its own data and responsibilities, and *could* act in isolation, but also *could* appear to be integrated with the other tools. It would be *as if* there were one "design file" that all the tools knew about, when in reality there isn't one. That's the dichotomy I was referring to - how the low-level design data is stored, and how the tools interact with that data on behalf of the user. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user