[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: [RFC 5/6] Use of X server clipboard
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/
jpd@xxxxxxxxx
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user