Re: gEDA-user: gEDA just hit SlashDotOrg

[spuzzdawg <spuzzdawg@xxxxxxxxxxxxx>]

   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]jpd@xxxxxxxxx

References

   1. http://www.noqsi.com/
   2. mailto:jpd@xxxxxxxxx


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