Re: gEDA-user: Blind and buried vias?

[Dan McMahill <dan@xxxxxxxxxxxx>]

Can we put an end to this thread?  How about this.  PCB is part of gEDA. 
  I'm a developer for both.  It is not a part of gaf (gschem and 
friends) but it is the most popular reason for using gaf.  You can argue 
all you want about exactly how much a part of gEDA PCB is, but it is a 
part.  Some times I work on gaf and PCB totally independently, some 
times I literally have had one emacs open with gschem source code and 
another with pcb source code.

Integration is not a bad thing but integration when done in a way that 
precludes using the tools in a non-integrated matter is bad and as far 
as I know *none* of the actual developers of any of the various tools 
falling either directly under the gEDA umbrella or in its drip line are 
proposing integration in ways that preclude the toolkit nature.  I also 
don't think any of the actual developers need constant reminding of this.

I will say that there are some very powerful features that you simply 
can't achieve without integration but that integration can, should, and 
if we ever get that far, will be done in a more generic way.  For 
example, at one point I had gschem schematic <-> pcb layout cross 
probing working.  Click on a schematic instance and pcb selects the 
corresponding layout instance.  Click on the layout instance and gschem 
selects the schematic instance.  In fact that code still exists in pcb 
and gschem as far as I know.  The only place where gschem knew about pcb 
was via a single scheme file which was loaded at run time.  All of the 
other code which was written to make this possible was totally generic 
and is there to benefit whatever other tool flow is desired.

No matter how you slice it the largest user base of gschem is using it 
for driving pcb and so it makes a lot of sense to talk about new 
features in the context of pcb.  Did I need to use pcb when trying to 
extend the scheme capabilities of gschem?  Of course not, but why not 
use the vehicle that is likely to see the most use.  Besides which, this 
is a volunteer project and developers are going to use the portions that 
are useful to themselves as the vehicle.  It doesn't mean we don't care 
about making sure the tools remain flexible.  I certainly don't speak 
for all the gschem developers but I suspect that gschem would have died 
long ago if it weren't for the pcb user base.  I would wager the break 
down is probably 70% of gschem schematics are to drive pcb, 10% for 
schematics for papers in school or journals, 15% for simulation, and 5% 
for everything else.  Doesn't mean we don't care about the 5, doesn't 
mean we need continual reminders of it either.

gaf could also benefit a lot from having the power needed to provide 
tighter simulation integration too.  It is really nice to be able to 
click and plot a node or back annotate dc node voltages or device 
operating points on a schematic.  It doesn't need to be done in a way 
that forces this work flow and again, no one who is actually writing 
code for the various tools is proposing that.  What I have seen though 
is numerous arguments of this type turning off some very capable people 
and actually hurting the progress which is needed to build on the 
toolkit nature of these tools.




Windell H. Oskay wrote:
> On Sep 27, 2009, at 5:16 AM, John Doty wrote:
>> Yes, pcb is not part of gEDA. It is a separate (older) development.
> 
> History aside (and like it or not) PCB *is* currently a de facto  
> member of the extended suite of gEDA  programs.
> 
> Ignoring this, or claiming otherwise, is frankly absurd.
> 
> 
>> I don't know who wrote that. gEDA and PCB are separate, independently
>> developed projects.  They have different source trees and conventions.
> 
> 
> That the extended gEDA suite contains separately developed programs,  
> with separate source trees, does not suddenly mean that one of the  
> programs just "doesn't count" when somebody asks a question about  
> it.   That's a poor excuse.
> 
> Also:  The current developers listed on both projects at sourceforge  
> have 50% overlap.  That's not exactly independent.
> 
> 
>> They were not originally designed for each other.
> 
> Nor were peanut butter and jelly, nor mac and cheese.  What's your  
> point?
> 
> 
>> 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.
> 
> You are implying that continuing to acknowledge PCB as one of the  
> extended suite of gEDA programs will lead to a loss in our valued  
> flexibility.  No one is saying that, and it's bad logic.
> 
> 
>> 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.
> 
> I think that all that anyone has asked is that you acknowledge the  
> integration that does already exist.
> 
>  From what I can tell, you're reasonably happy with that level of  
> integration-- i.e., not much integration at all.  As you've said, it  
> is a separate program with a separate source tree.
> 
> 
>> The discussions of gEDA's shortcomings here are disturbingly short-
>> sighted.
> 
> Maybe.  But probably not as short sighted as your contention that  
> acknowledging PCB is "dangerous."
> 
> -Windell
> 



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user