Re: gEDA-user: Blind and buried vias?

[John Doty <jpd@xxxxxxxxx>]

On Sep 26, 2009, at 3:07 PM, spuzzdawg wrote:

>
>    Jon,
>    You seem to consistently bring up this argument and I really think
>    it's to the detriment of the list. I'm sure that by now,  
> everyone on
>    this list is quite aware that in you're opinion, PCB is not part of
>    gEDA

Yes, pcb is not part of gEDA. It is a separate (older) development.

> and not a single question should ever be asked about it.

It would be nice if pcb had its own list, but I don't really mind  
that either.

> I'm not
>    sure why it's apparently irrelevant that the accepted predominant
>    workflow is from gschem to pcb

So what? What are all those other back ends for? Aren't they important?

> or that pcb is a member project of the
>    geda project. If member projects and affiliated projects aren't
>    considered part of gEDA then I'm curious as to what you define  
> as gEDA
>    and what topics you define as appropriate for this list.

The issue isn't what topics are appropriate. The issue is keeping the  
interfaces clean and flexible. To do that, you have to remember what  
the interfaces are.

> Someone on
>    the list asked for help with blind and buried vias and you're  
> response
>    was "pcb is not part of gEDA", I'm sure the OP found this  
> information
>    quite useful.

The OP said:

> What's the current and planned state of support for blind and/or  
> buried
> vias in the gEDA system?

That's like asking "what's the state of support for driving Phillips  
head screws with a handsaw?".

>    It might sound a little harsh to say these things but I've noticed
>    that you do it quite often.

I have a thick skin.

> Anyone who brings up a point about how
>    geda/gaf/pcb could be more useful, more user friendly etc

More useful and friendly to *what kind* of user? The kind that would  
prefer spending an hour mousing around to solve a problem once, or 15  
minutes writing a script to solve it for all time?

> quickly gets
>    shot down by you with the same message, that gEDA is a toolkit, its
>    flexibility is its power and problems with pcb aren't problems with
>    geda.

The fact that the handsaw can't drive a screw isn't a problem with  
the handsaw. Gluing a screwdriver to it would not be an improvement.  
But a handsaw and a screwdriver can work effectively together, just  
like gEDA and pcb.

> You use the line about gEDA being a toolkit to justify any of
>    its shortcoming despite the fact that gEDA itself doesn't even
>    consider itself this way. From the website:
>    "Currently, the gEDA project offers a mature suite of free software
>    applications for electronics design, including schematic capture,
>    attribute management, bill of materials (BOM) generation,  
> netlisting
>    into over 20 netlist formats, analog and digital simulation, and
>    printed circuit board (PCB) layout."

I don't know who wrote that. gEDA and PCB are separate, independently  
developed projects. They have different source trees and conventions.  
They were not originally designed for each other. That they play well  
together is a testimony to the power of clean interface design. Let's  
not forget that, because if we do we will lose that power.

>    My point is that your one man war gEDA terminology doesn't help
>    anyone.

I disagree. The abuse of terminology here is dangerous, because it  
encourages the delusion that gEDA and pcb would be better if they  
were more integrated. Integrated tools may be easier to use in some  
sense, but they don't have gEDA's productivity potential.

> It serves only to distract meaningful discussions about gEDA's
>    shortcomings and ways in which it could be improved as well as
>    preventing posters from actually getting their questions answered.


The discussions of gEDA's shortcomings here are disturbingly short- 
sighted.

People want prefabricated heavy symbols in a library, not considering  
how massive the problem is. Too many variables. What we need is an  
easier way to customize symbols for a particular project. And perhaps  
better BOM post-processing support, so the user can say "I want to  
use footprint xxx and vendor part number yyy for all 100nF X5R  
capacitors in this project". gattrib is a nice tool for quick "touch  
up", but not productive when you have hundreds of footprints to change.

The biggest hole in the gEDA documentation concerns the scripting  
that gschem/gnetlist can do using Scheme. There's no real API  
documentation here, so few are aware of the latent power here, and  
even fewer know how to harness it.

We need to refactor gnetlist: the fact that the front end hides  
critical information from the scripted layers causes problems and  
prevents back end development in some directions. But the proposed  
solution to the most prominent of these problems is to make the front  
end more complex, and therefore make the needed refactoring harder.

And many who find "shortcomings" in gEDA don't want a toolkit. But  
I'm extremely grateful that gEDA *isn't* a massive time-wasting  
integrated point and click thing designed for sales rather than  
sustained, efficient problem solving. I hope it stays that way.

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