Re: gEDA-user: Solving the light/heavy symbol problem

[DJ Delorie <dj@xxxxxxxxxxx>]

> 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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user