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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
