Re: gEDA-user: Matching footprints with symbols

[John Doty <jpd@xxxxxxxxx>]

On Apr 16, 2010, at 5:15 PM, Windell H. Oskay wrote:

>> The two projects are able to work together *because* they were
>> intentionally designed with clean interfaces, and no unnecessary
>> entanglements. You propose to throw away the very virtue that made the
>> partnership possible in the first place. Some of us want to keep the tools
>> open to other partnerships.
> 
> John-- He was proposing no such thing and you know it perfectly well.  
> You don't need to keep making up stuff like this.
> 
> You have told us all *many* times how important it is that the gEDA suite
> is made up of independent "toolkit" programs that have clean interfaces,
> supporting all kinds of unique workflows.  I think that there's a
> consensus here that this is a genuine strength of the gEDA suite. Yes, we
> agree with you.  We also know that you personally have a special workflow,
> and *nobody* is trying to take that away from you.  So far so good.
> 
> But, maybe it's time that you face facts:
> 
> 1.)  Some of us think that it's actually okay to use gschem together in a
> workflow with pcb.

I do too. I might even do so soon: I have a project in mind.

> 
> 2.)  Some of us think that it's okay to add additional, easy-to-use (and
> yes, integrated) interfaces so long as they don't interfere with existing
> scriptable command-line operation.

In principle, this could be done. In practice, it won't: the high road to flexibility is maximal simplicity. Nobody really understands the limits of gEDA's flexibility, as shown by the recent hydraulics discussion. Without such knowledge, the only way to preserve what we've got is to keep it as clean, well factored, and agnostic of the flow as possible.

>  I personally think that it's good (in
> general) to build the gEDA community.  Starting people off with an example
> workflow (e.g., gschem to pcb) may be a good way to get them in the door--
> so that they can start to see how they might instead design more unique
> workflows between the different programs.

Sure, that's fine. But one problem is that recent "improvements" to the documentation strongly suggest that that's the *only* flow.

> 
> 3.)  You're too late.  There is already (more than one) existing
> integration between gschem and pcb.  Fortunately, gsch2pcb is an
> independent program, so changes to it do not "throw away" the clean
> interfaces between the other programs, but instead makes use of it.

I have no objection to this. This is clean: neither gschem nor pcb need adapt to the special features of the other. I've written several gnetlist back ends myself: again, this is good, clean, modular fun. It would be nice to improve the factoring of gnetlist to allow more flexibility, though. Real control of hierarchy would be nice.

> 
> 
> On the one hand, you seem to value gEDA, its independence between
> programs, and the fact that anyone can write their own customized scripts
> to make an efficient custom workflow between the programs that they want
> to use. However if that's really the case, you should also understand
> that it's okay if people do exactly that, but with workflows that are
> different from your own.

I have several workflows. I'll probably use a different one yet for the next project. The project decides, and the genius of gEDA is that I can let the project decide.

> 
> For example if people want to discuss modifications to gsch2pcb (or other
> programs that you don't use), the very least that you could do is stay out
> of it.  It's not actually necessary for you to go out of your way to bash
> them.  It gets old pretty quickly; please give it a rest.

You apparently didn't understand my post. I saw:

> the entire package of tools
>   could be combined under a single IDE and act like a unified suite of
>   tools,

That notion frightens me. That's not about improving gsch2pcb. But the other thing is that these issues are common to many flows: why implement the fix in a special pcb-specific tool? gsch2pcb should only handle the special issues of that interface. Indeed, it would be better if gsch2pcb didn't exist, and whatever prevents gnetlist from doing this job was fixed. That would presumably benefit many flows, not just pcb.

> 
> We mostly agree with you.  It would nice if you agreed with you too.

I'm disturbed by the way that the narrow interests of the users of a single back end have come to dominate the discussion.


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