On Sep 27, 2009, at 10:54 AM, Martin Maney wrote: > I was going to comment on one point, but once you start writing... > > On Sun, Sep 27, 2009 at 06:16:42AM -0600, John Doty wrote: >> 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? > > I suppose it depends on whether gEDA is only for those who use it for > hours every day and thus find the cost of learning to and configuring > things to work just the way they want them an obvious net win, or if > it's desired for it to be useful to a larger audience.
I think you have it exactly backwards. When you work on a project every day it isn't hard to remember the project structure and the operations you need to manipulate it. But the part-timer can't remember that stuff: it's extremely important to automate it. > I'd be an > example of that - although I have rather enjoyed the work I did > about a > year ago using gEDA, the fact is that I haven't had occasion to touch > it since those boards got sent off. That's when the scripts are essential. They embody the project structure in a way that's easy to use. It's very handy to be able to go back to a project you haven't touched for a couple of years, make a small change, type "make", and have all of the data products rebuilt. > Sure, I have other projects in > mind, but they've been stuck on the back burner, and seem likely to > stay there for some time yet. Too many todos, too little time. But I'm a part-timer, too. I've been using gEDA for about seven years, but the majority of my work over that time has been in spacecraft mission operations and data analysis. Electronic design is a sideline. But gEDA enables an individual part-timer to tackle big projects because it enables a high productivity approach. > >> 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. > > +1 about gattrib's shortcomings when there's more than a few items to > tweak. I would like to add that some of that seems to be a really > weird UI - things behave oddly compared to other GUI tools, IMO. > OTOH, > if there were a rich library of those heavy symbols you dislike, I *love* heavy symbols. I have plenty. Ales calls me a heavy symbol advocate. But it's everything in its place. When you take into account all of the variables, the probability that any particular heavy *library* symbol will match the needs of any particular project approaches zero. Despite all of the talk, I predict that gEDA will never have a satisfactory library of heavy symbols: the job is simply too big. On the other hand, when you're putting together a project, you have some idea of what those needs are, so that's the time to add "weight". And for big projects, it's handy to have a set of heavy symbols identified by role: "bypass_capacitor", "low_noise_opamp", etc. Then, as your needs change, you can change a symbol and get all similar parts changed automagically. Or you can import the schematic page into a different project built around a different parts stock and have it "just work". > there'd be a lot less need for tweaking things (at least IME). The only practical approach is to make the tweaking easier. > But I > have to agree that creating a huge library like that shouldn't be part > of gEDA's mission, especially when manufacturer's so often make this > stuff available... but in formats gEDA can't use. Yeah, it's hard. > > The database-driven idea sounds wonderful, but my impression is that > it's a hella bike shed - lots of talk about it but little if anything > of general interest gets done... or maybe everyone's waiting for one > of the personal hacks to be just the color and glossiness they wish > for. And it still sounds like a lot of setup work for casual or > occasional use. We already have a database structure if you look more than skin deep. A .sym file is a fine container for relations, so a directory containing .sym files is a relational database. Do we really need more? > >> 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. > > +1e6 - not that Scheme is my favorite scripting language, but if there > were a documented API it would be a viable option. > >> And many who find "shortcomings" in gEDA don't want a toolkit. > > I have very mixed feelings about that, though the above has mostly > come > down on one side. And I'm not sure I'd call it a toolkit - some of > the > pieces just don't work together very well. The mess of issues that > arise between gschem and PCB are perhaps the most discussed, but all > the parts I've had occasion to use feel more like a random collection > of tools than a proper toolset - one size Phillips screwdriver, a > couple of flat blades but none really small or really large, a hacksaw > blade but you have to make your own frame for it... The individual > parts are good quality, but... Well, of course you have to use it with other tools: gEDA only has the special-purpose parts of the kit. "make" may be the most important tool in a gEDA flow. > >> But I'm extremely grateful that gEDA *isn't* a massive time-wasting >> integrated point and click thing designed for sales > > So am I, but I don't think that's the only kind of better-integrated > thing that *could* be made, even if the commercial EDA toolmakers > don't > have a clue about it. :-) > >> I hope it stays that way. > > I hope gEDA can do better, so that I can curse it less next time I > reach that stage! > Learn make. While intended for software development, it's effective whenever you generate data derived from other data (which is pretty much everything you do with a computer!) so long as the tools support a shell scripted flow. Unfortunately, describing simple tools simply seem to be a lost art in the 21st century. Fortunately, you can learn the essence from the master: http://eprints.kfupm.edu.sa/49660/1/49660.pdf John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user