On Friday 03 March 2006 06:42, Stuart Brorson wrote: Before you read this one, please bear in mind I'm not trying to be critical of the program, it shows a lot of promise. I'm just writing in my usual style, so take it with a grain of salt.
> Note that I do belive that you *shouldn't* need to read documentation > to make a program work. Documentation is the tricky part. What I did look through wasn't much, admittedly, but I side with you - documentation should not be necessary to use a program, it should only be needed if you get stuck. Until just now, I never knew there were links to a wiki and a tutorial on the website. > ... However, you appeared to be stuck more than once... Actually I never got *stuck* exactly. I was going through the usage of the program as I see it from the perspective of a seasoned Linux user who is new to gEDA. For example, when I ran into the slotted components issue with the 7400, I didn't know what a "slot" was. To me, they're individual gates, not slots. Consider this: When you work at a grocery store, you learn certain terminology.. "blocking" means to push all of some item to the back of the shelf, while "air space" means the empty space betwen adjacent products. To the average person who has shopped there all her life prior to working there, these terms probably refer to football and airplane flight, respectively. Perhaps it would be a good idea to show the user normal everyday words in stead of 'refdes' and 'slot' and whatever else. It makes a lot more sense at first, and seems less daunting. When I'm confronted with weird terms like these, I think "Huh? What does this mean? This is too complicated for me." In the case of the gnetlist procedure issue, if it hadn't explicitly told me which file it had tried to load and from where in the filesystem, I would have had to try go Google for a correct answer. Likely as not, it would not have helped (Google's search result quality has been steadily declining over the last year or so). Nevertheless, gnetlist should at least choose a default procedure to use when none is specified, and it should be in keeping with the basic theme of the package as the website seems to suggest - export a file from gSchema to PCB. > 3. Bugs in "geda", the deprecated project manager. The wiki, > discourages its use. Fair enough, it is deprecated. However, when you first visit the gEDA website you are greeted with a big, bold, yellow "gEDA" graphic at the top. The first thing that comes to mind is "ok, when I download this, just type `geda` to get started". Then I get to the download screen and I am overwhealmed by the sheer number of individual tools, support libraries, and so on. > 4. Issues having to do with the philosophy of gschem's (or any EDA > tool's) usage... > > Also, you can configurably have auto-refdesing performed within > gschem... > > (Indeed, this brings up the whole interesting idea of making the > various settings in gschemrc settable within gschem via a pull-down > menu item called "settings". Hmmmm . . . . .) This is precisely what gSchem should do. While I was layout out the PowerSID project (the board I was working on when I filed the 'stale netlist' bug), I found myself having to name every single individual component one at a time. After the first 10 or so (out of about 50 small 200-mil capacitors and resistors, along with about 15 IC's), it became very tedious. as a side note, like gSchem, PCB doesn't auto-number it's parts, and there doesn't seem to be a way to tell it to do so either. -- "Sometimes paranoia can be helpful. Usually it isn't, and when you learn that, life improves." Vanessa Dannenberg
