I think that this is basically an argument in usability vs flexibility. John is basically arguing that gEDA's lack of restrictions means that it can be used for a multitude of tasks. A person's workflow can be developed to the user's taste rather than through wrestling against the program. On the other hand, Kai is arguing that you need to be a gEDA expert, understand the intricacies of backends and front ends to accomplish even the simplest task. My opinion is that to a certain extent, both approaches are correct. If I'm designing a circuit board I want to be able to click on a component and add it in to my schematic and then flip to pcb view and put it on the board with some tracks. With gEDA I need to understand symbol properties to assign a footprint. I need to know about M4 footprints vs the newer style. The only way to find out the correct footprint name to use is too look through the footprint files in a folder that changes depending on the method of install. If the footprint doesn't exist I need to create it using a cryptic language. Some basic functions, like moving a component to an absolute location, only have a command line action with no gui counterpart. Users then have to email the mailing list to find out what all the hidden functionality is because the documentation exists but is very hard to find and decipher. Sure gEDA is more flexible than other programs, but this flexibility is really a hinderence to my workflow and I'm sure others are turned away for similar reasons. Nick
>> >> So we need even greater flexibility. Less hard-wired, fewer >> barriers to >> arbitrary transformations. > > No, we need import and export mechanisms that work. Right now, > there is > none. Lack of features is the opposite of flexibility. Wrong. Ever use the language PL/I? Loaded with every feature the best computer scientists IBM could find asked for. Touted as the universal language. Displaced by the much simpler C language (to the extent that a universal language makes sense). I'm an old PL/I programmer (learned it 40 years ago, yikes). Believe me, C is much more flexible and easy to use. All those features just got in the way. Ever use the Viewlogic EDA suite? I have. gEDA is very similar, but has many fewer features. Hurray! Again, that makes gEDA more flexible and easier to use, especially if your needs are a bit eccentric. And in the Viewlogic case, lots of features led to lots of bugs. > In the case of export, the basic problem is that the features are in the wrong place. The gnetlist front end provides hard wired features that instead belong in the convenience functions in gnetlist.scm. If the front end stuck to parsing files on request from the back end and/ or the convenience functions, the back end could see all of the data if it needed, and transformations to formats other than flat netlists and BOM's would be possible. Import is a different problem. Parsing a complex input format is trickier than outputting it, especially when it's undocumented. There's probably no general framework that makes sense here: it'll require separate tools. In a sense, it's like those gnetlist back ends: the tools will mainly be written by those who want to do the importing. But it's an order of magnitude harder. My old Viewlogic schematics aren't relevant enough to today's jobs to make it worthwhile for me to tackle this. John Doty Noqsi Aerospace, Ltd. [1]http://www.noqsi.com/ [2]...@noqsi.com References 1. http://www.noqsi.com/ 2. mailto:j...@noqsi.com
_______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user