John, For a simulator, wouldn't you want to select a section of a schematic and say simulate this?
I think, thinking about scenarios leads to requirements. So to say be able to select an area of a schematic and then transmute that schematic section into the needs of the next application. If the next application doesn't support the paste then of course I would like that LOGGED. Steve Meier On Fri, 2009-01-16 at 21:25 -0700, John Doty wrote: > On Jan 16, 2009, at 8:48 PM, DJ Delorie wrote: > > > > >>> A program should do one thing well. Capturing circuit information > >>> (regardless of what that is) and providing that to a layout system > >>> (regardless of what *that* is) is that one thing here. > >> > >> As stated by you, that's two things. > > > > Sigh. I'll try to word it as one thing. "Be a design capture > > front-end for layout systems". Please don't get all anal-retentive on > > me. > > That's still not one thing, or will pcb support ASIC layouts in the > future? Furthermore, we want gschem to be a front-end for simulation > systems. And what is the IEC60417 symbol library for? gschem does > "one thing well" but that "one thing" goes far beyond what pcb or any > other program can serve as back end for. That's how well factored, > flexible software works. > > > > >> Yes, let's not set our scope too narrow. Specializing on the gEDA- > >> pcb flow is exactly the sort of narrow scope I wish to avoid. > > > > That's not what I meant, and you know it. I get enough of that crap > > at work, I don't need it here too. > > But I don't know that. I fear gEDA is evolving toward specific > scenarios that don't reflect the needs of my projects. And despite > the best intentions of the developers, being scenario-driven will > inevitably reduce gEDA's flexibility. That's what happens as software > evolves, but it happens faster if nobody digs in their heels a bit. > > > > > gschem should specialize at being a way to get circuit designs from > > the user's brain to a layout system. > > Too far. gschem should capture topology. That's what a schematic > represents. Layout is a separate problem. Geometry and topology are > distinct mathematical concepts for good reason. > > > I don't care which layout system > > it is, but once the user has chosen one, gschem should integrate with > > it fairly well. If the user copies from gschem and pastes in pcb, it > > should do the right thing for feeding information into pcb. I don't > > care if it's the gschem executable, some scheme script, a callout to > > gnetlist, or email to your mother's neighbors that makes it happen. I > > just want it to happen, and I want it to appear seemless and obvious > > to the user. > > Please don't minimize the subtlety and complexity here. This is not > trivial, and is certain to have adverse consequences for flexibility > that we cannot anticipate. But most combinations of a well-factored > set of tools will work. > > > > > If gschem has to use a bunch of specialized "do only one thing well" > > helpers, so be it. I just don't think it's right to expect all the > > users to know how to run each program separately. gschem should have > > enough hooks in it to allow any layout system to (somewhat) seamlessly > > integrate with it, through whatever helpers and middleware are needed. > > Users shouldn't have to exit gschem, run gattrib, exit that, run > > gsch2pcb, run pcb, exit that, run "make", run gschem again, ad > > infinitum. They *can* but they shouldn't *have to*. > > Exit? Not necessary. Just a window per GUI and a window for "make". > > > > >> but gEDA->Osmond is working so well for my MIT projects that it > >> makes me wonder. > > > > So use Osmond, I don't care. You should be able to copy/paste from > > gschem to Osmond too, and have the right footprint show up there. Or > > did you want a separate gschem_to_osmond_gui_cut_paste program to do > > that for you? > > No, I want to keep separate things separated. Edit schematic in > gschem, "fs", "make", layout in Osmond (or mail design files to the > Osmond expert). I don't expect radical cut and paste to work. > Mathematica (one of my favorite tools) tries that, and often fails, > although Wolfram has vastly more resources than we do. > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > [email protected] > > > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
