Re: gEDA-user: plugins (was: How can you help...)
Abhijit Kshirsagar wrote: Somehow missed this thread and replied on the other one... Count me in for documentation. Please let me know what I can do. I still have to decide, where to start. An overview? A getting started? A HOWTO? A table of contents to be filled? Some of the documentation I have written previously is here: gEDA-Tutorials.pdf on https://sites.google.com/site/abhijit86k/linux/geda Nice. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 Moderation of geda-user seems to be lifted somewhat, lately. I am still unhappy with it. Why? Because it is completely nontransparent. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: reasons for wikibook (was: plugins)
Vladimir Zhbanov wrote: On Wed, Sep 07, 2011 at 10:51:31PM +0200, Kai-Martin Knaak wrote: I am close to start off a gEDA wikibook (http://en.wikibooks.org). Would you join the effort? How about updating the existing wiki documentation? Reasons to go for wikibooks: a) IMHO, it is good practice to have a user manual completely separate from documentation of features, formats and APIs. While the latter has to be complete, comprehensive and super correct, the former should focus on ease of use. These are conflicting goals. Think automatic extraction from the source versus a) wikibooks provides a full fledged environment geared toward cooperative work on text documents. It comes with all the communication features you need (discussion page associated with each content page, user discussion, email). b) mediawiki syntax is rich in features and proven to work for large groups of authors. c) There is a host of howtos and help pages for each and every feature that mediawiki delivers. d) There are versions in many languages. This is good for translation. e) The entry barrier is as low as it can get. If general readers spot a glitch, they can press the edit button correct the error and are done. This provides a opportunity to foster participation of more users. Compare this to the circumstances inside the geda project. You need to send an email to an admin to even see the edit buttons in the gpleda-wiki. Changes to the pcb manual require git patches and an approval by core devs like changes to the code in git-head. Given the consistent tendency toward more wall-in over the years, I don't expect this attitude to change anytime soon. f) The geda devs have no more say in what goes in a wiki book, than any other user. g) There is a kicad wikibook. http://en.wikibooks.org/wiki/Kicad ---)kaimartin(--- -- Kai-Martin Knaak, Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 Moderation of geda-user seems to be lifted somewhat, lately. I am still unhappy with it. Why? Because it is completely nontransparent. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: plugins (was: How can you help...)
My suggestion is to first create an outline. The first n sections should be in tutorial form, using a small example, and focusing on the main steps, beginning with installation of the tool(s), problem statement (going from schematic to board layout to what needs to shipped to a board house). This section should contain a number of subsections (1-2 pages in length for each subsection) that is a susccinct description of the the task. Related, but not main stream topics can be forward referenced to another section later in the document. For example, making a design from the built in libaraies would be in the first major section, with a forward pointer to a detailed section about how to make your own objects in libaries, and yet another subsection could deal with library management (concepts and approaches, perhaps with one example illustrated - for example, managing libraries on a personal workstation). So, the doc would have two sections: Section 1 - Main tutorial Each subsection in the tutorial would be listed in the outline, so one could read through the outline and see the steps involved in producing a board. Section 2 - Expanded topics referenced in the tutorial Each subsection in this section would address a specific topic referenced in Section 1. Each subsection should be self contained, ie. how to create a symbols, how to manage symbol libraries, etc. Lots of screen shots should be in both sections as appropriate I would be happy to review the outline and the development, and provide feedback. -John On Sun, Sep 11, 2011 at 11:37 PM, Kai-Martin Knaak [1]k...@familieknaak.de wrote: Abhijit Kshirsagar wrote: Somehow missed this thread and replied on the other one... Count me in for documentation. Please let me know what I can do. I still have to decide, where to start. An overview? A getting started? A HOWTO? A table of contents to be filled? Some of the documentation I have written previously is here: gEDA-Tutorials.pdf on [2]https://sites.google.com/site/abhijit86k/linux/geda Nice. ---)kaimartin(--- -- Kai-Martin Knaak Email: [3]k...@familieknaak.de [4]http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 Moderation of geda-user seems to be lifted somewhat, lately. I am still unhappy with it. Why? Because it is completely nontransparent. ___ geda-user mailing list [5]geda-user@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:k...@familieknaak.de 2. https://sites.google.com/site/abhijit86k/linux/geda 3. mailto:k...@familieknaak.de 4. http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 5. mailto:geda-user@moria.seul.org 6. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reasons for wikibook (was: plugins)
a) IMHO, it is good practice to have a user manual completely separate from documentation of features, formats and APIs. While the latter has to be complete, comprehensive and super correct, the former should focus on ease of use. These are conflicting goals. Think automatic extraction from the source versus See http://www.delorie.com/pcb/docs/ for my preferred breakdown of the PCB docs. I think this matches what you're suggesting. e) The entry barrier is as low as it can get. If general readers spot a glitch, they can press the edit button correct the error and are done. This provides a opportunity to foster participation of more users. Compare this to the circumstances inside the geda project. You need to send an email to an admin to even see the edit buttons in the gpleda-wiki. Changes to the pcb manual require git patches and an approval by core devs like changes to the code in git-head. f) The geda devs have no more say in what goes in a wiki book, than any other user. While I appreciate the desire to streamline the editing process, I see two problems with your approach: 1. The easier it is to contribute, the more likely you are to be vandalized. Wikipedia has seen plenty of this problem. You need some method of authorizing trusted contributors and approving changes by others. 2. You should not choose a solution based on alienating the developers. They're your greatest source of information on how the tools work. Note: I'm not complaining about your choice, just your reasons. Given the consistent tendency toward more wall-in over the years, We've been adding more people with commit access over the years. I don't see this consistent tendency you speak of. I don't expect this attitude to change anytime soon. From my point of view as an admin, I see a few users who wish to be contributors but have a you must do it my way attitude. It is difficult to accept contributions from such individuals because any requests for changes to better align with the goals of the project are met with harsh rebuttals and personal attacks (like this one). For such contributors, it is far easier to just say no than to try to work with them. Compare with other contributors who are willing to compromise, deferring to the admins until they understand what's going on, and are granted priviledges and responsibilities within the project. In general, if a contributor sees an attitude in a project, it is their reponsibility to adjust their attitude to match the existing group, not the group's responsibility to match each new member's individual attitude. This is not specific to gEDA, I've seen this in every project I've contributed to. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: CERN goes for KiCAD
On Sun, 11 Sep 2011 13:16:23 +0200 Rubén Gómez Antolí l...@mucharuina.com wrote: Is something how Kde us Gnome? Because after of years of desktop wars, both proyects colaborate in base (freedesktop) and expand his own style. There are something to learn in our own free software history? That's a good point. Where could things be best shared between KiCad and gEDA? While it would be nice to share a common schematic/PCB layout file format, that seems difficult given the different approaches taken by both tools. My initial thought is that the biggest value-to-effort ratio would be from being able realized by being able to share symbols and footprints between the tools. Of course even this has some serious difficulties: consider all the special attributes and such required for proper gschem symbols. Perhaps gschem's format is detailed enough that KiCad symbol information could be inferred from it. Footprints might be simpler to share since there seem to be fewer tool-specific details needed (just defining copper areas/pads, pins/holes, solder mask and paste, silk screen lines). Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb “Optimize routed tracks” problems
I've been trying to use the pcb track optimization tools on a board which I've manually routed. I tried essentially all the options on the Connects | Optimize routed tracks menu. However, I've run into a couple of problems: 1. My board has an LQFP48 footprint rotated 45 degrees. Whenever I try to use the optimization tools, weird stairstep tracks appear on this IC's pads, shorting all of them together. 2. The optimization tools violated the DRC minimum spacing constraints. I removed the LQFP48 IC and instead put some circular “test pad” footprints in place of each of the IC's pads. I was then able to get the optimization tools to sort-of-work. However, the tracks were pulled too close to some other pins and it violated DRC minimum copper spacing. Also, my tracks weren't very nicely pulled and optimized either. Has anyone encountered these problems? What is the status of the pcb track optimization features? Do they perform better for automatically-routed tracks? Are they useful only for very simple layouts? Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb “Optimize routed tracks” problems
1. My board has an LQFP48 footprint rotated 45 degrees. The ability to rotate parts happened after the optimizer work. Any math majors want to take this one? Do they perform better for automatically-routed tracks? They were intended to clean up after the autorouter. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: CERN goes for KiCAD
Hi all, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Colin D Bennett Sent: Monday, September 12, 2011 6:43 PM To: geda-user@moria.seul.org Subject: Re: gEDA-user: CERN goes for KiCAD On Sun, 11 Sep 2011 13:16:23 +0200 Rubén Gómez Antolí l...@mucharuina.com wrote: Is something how Kde us Gnome? Because after of years of desktop wars, both proyects colaborate in base (freedesktop) and expand his own style. There are something to learn in our own free software history? That's a good point. Where could things be best shared between KiCad and gEDA? Footprint editor ? https://github.com/bert/fped Fped lives in Ubuntu and Fedora, and maybe other distros, with support for KiCAD users. Anyone interested in a parametric footprint editor with support for pcb ? Just clone, add code and stuff, and send patches to here. This way we can have common files for interoptable footprints. While it would be nice to share a common schematic/PCB layout file format, that seems difficult given the different approaches taken by both tools. My initial thought is that the biggest value-to-effort ratio would be from being able realized by being able to share symbols and footprints between the tools. Of course even this has some serious difficulties: consider all the special attributes and such required for proper gschem symbols. Perhaps gschem's format is detailed enough that KiCad symbol information could be inferred from it. Footprints might be simpler to share since there seem to be fewer tool-specific details needed (just defining copper areas/pads, pins/holes, solder mask and paste, silk screen lines). Regards, Colin Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: CERN goes for KiCAD
That's a good point. Where could things be best shared between KiCad and gEDA? Footprint editor ? https://github.com/bert/fped Fped lives in Ubuntu and Fedora, and maybe other distros, with support for KiCAD users. Anyone interested in a parametric footprint editor with support for pcb ? Just clone, add code and stuff, and send patches to here. This way we can have common files for interoptable footprints. It would be quite handy to make a backend for fped that outputs PCB footprints. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb “Optimize routed tracks” problems
On Mon, 12 Sep 2011 19:04:35 -0700 Andrew Poelstra as...@sfu.ca wrote: On Mon, Sep 12, 2011 at 02:38:20PM -0400, DJ Delorie wrote: 1. My board has an LQFP48 footprint rotated 45 degrees. The ability to rotate parts happened after the optimizer work. Any math majors want to take this one? I'm interested, but time-strapped. Can you give me a quick outline of what Optimize routed tracks is supposed to do and what source files it uses? I looked back at DJ's page on the pcb trace puller http://www.delorie.com/pcb/puller/ and realized that the instructions there rely on using arcs in the tracks. Perhaps a sequence of lines is not pulled properly? My goal was to do some rough, but not pretty (nor tightly spaced) routing of traces, then use the puller to pull all my parallel traces nice and tightly together as they bend around other parts, and to eliminate all the “jaggies” as they stairstep down together in certain cases. Anyway, it sounds like in their current state, the Optimize Tracks tools are not really usable for manually routed boards. If they would at least adhere to DRC constraints, that would make them more of an option. (Note that my initial traces before running the optimizer did pass DRC with no errors.) Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reasons for wikibook (was: plugins)
On Sep 12, 2011, at 8:43 AM, DJ Delorie wrote: developers. They're your greatest source of information on how the tools work. At the reference manual level, perhaps (although when I documented the gnetlist scheme primitives I didn't get much developer help). But at the level of toolkit use, I don't think so. The developers appear to to be focused on a small subset of gEDA's broad application space. 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
Re: gEDA-user: plugins (was: How can you help...)
On Sep 12, 2011, at 8:05 AM, John Hudak wrote: So, the doc would have two sections: There's nothing whatever preventing you from creating gEDA documentation and publishing it on your own site (or gedasymbols.org: even us black sheep are accepted there). That's what Stuart Brorson did when he created his great tutorial, even though he was an insider. 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
Re: gEDA-user: CERN goes for KiCAD
Hello: El 12/09/11 18:42, Colin D Bennett escribió: On Sun, 11 Sep 2011 13:16:23 +0200 Rubén Gómez Antolíl...@mucharuina.com wrote: Is something how Kde us Gnome? Because after of years of desktop wars, both proyects colaborate in base (freedesktop) and expand his own style. There are something to learn in our own free software history? That's a good point. Where could things be best shared between KiCad and gEDA? While it would be nice to share a common schematic/PCB layout file format, that seems difficult given the different approaches taken by both tools. My initial thought is that the biggest value-to-effort ratio would be from being able realized by being able to share symbols and footprints between the tools. Of course even this has some serious difficulties: consider all the special attributes and such required for proper gschem symbols. Perhaps gschem's format is detailed enough that KiCad symbol information could be inferred from it. Footprints might be simpler to share since there seem to be fewer tool-specific details needed (just defining copper areas/pads, pins/holes, solder mask and paste, silk screen lines). Sure. Start with a common schematic/PCB layout file format or work in a export/import tool is a excelent idea. After this, what about these basic library from Kai Martin? I suppossed that Kicad people wants a basic library too. I'm not a developer but I suspect that there are some tools too, like a good autorouter, that both apps can call. These are the base, beyond each app can run his own way. Perhaps, someone of the gEDA developer should contact with Kicad developers? Maybe we discover that Kicad people wants to earn that we say. In other way, what we lost? Regards, Colin Best regards. Salud y Revolución. Lobo. -- Libertad es poder elegir en cualquier momento. Ahora yo elijo GNU/Linux, para no atar mis manos con las cadenas del soft propietario. - Desde El Ejido, en Almería, usuario registrado Linux #294013 http://www.counter.li.org ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb “Optimize routed tracks” problems
I'm interested, but time-strapped. Can you give me a quick outline of what Optimize routed tracks is supposed to do and what source files it uses? I looked back at DJ's page on the pcb trace puller http://www.delorie.com/pcb/puller/ and realized that the instructions there rely on using arcs in the tracks. Perhaps a sequence of lines is not pulled properly? There are two different tools - the trace optimizer moves orthogonal traces to minimize overall trace length, and the puller does the whole curvy-arc thing. The optimizer needs some work to understand 45-degree pads, and polygon planes. Should be somewhat straightforward, see djopt.c. The puller needs more work as it's dealing with precision errors and bookkeeping - it tends to wrap traces around themselves, for example. It uses a more complex vector math too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Speaker SPICE modeling with gschem and ng-spice/gnucap
Hi! I have been playing with one guitar amplifier project for a while and so far the amplifier design has been more or less copy and paste and simulate and guess from graphs. However I bumped in net this blog post http://nordicnerd.blogspot.com/2011/08/active-speakers-spice-with-actual-audio.html Is it possible to do same thing? Input wav to simulator and get speaker's output and hear it? I know it's not perfect but it could be very helpful. Has someone done this before and provide some hints, examples or links? Best regards, Hannu Vuolasaho ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Speaker SPICE modeling with gschem and ng-spice/gnucap
On Mon, Sep 12, 2011 at 2:09 PM, Hannu Vuolasaho vuo...@msn.com wrote: Hi! I have been playing with one guitar amplifier project for a while and so far the amplifier design has been more or less copy and paste and simulate and guess from graphs. However I bumped in net this blog post http://nordicnerd.blogspot.com/2011/08/active-speakers-spice-with-actual-audio.html Is it possible to do same thing? Input wav to simulator and get speaker's output and hear it? I know it's not perfect but it could be very helpful. Has someone done this before and provide some hints, examples or links? Output is really easy to get from ngspice in the form of a raw file. There are some python modules out there that do a good job of reading this. As far as input, I see two options. One is to embed a pwl (piece wise linear) b source (or xspice source for more smoothing) into your circuit. You'd want to make a script that would read in the the wav data, and output a pwl. Your other option would be to use a digital source, which can also read from a file but you'd get digital data for which you'd need to build a dac (possible out of xspice dacs). In either case, You'd probably need some additional elements to remove the high frequency artifacts from the signal and to give it the appropriate impedance. For the most part though, I would just run through a number of different frequency sine waveforms and see what kind of distortion you get. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Speaker SPICE modeling with gschem and ng-spice/gnucap
On Sep 12, 2011, at 3:09 PM, Hannu Vuolasaho wrote: I have been playing with one guitar amplifier project for a while and so far the amplifier design has been more or less copy and paste and simulate and guess from graphs. However I bumped in net this blog post http://nordicnerd.blogspot.com/2011/08/active-speakers-spice-with-actual-audio.html Is it possible to do same thing? Input wav to simulator and get speaker's output and hear it? I know it's not perfect but it could be very helpful. Has someone done this before and provide some hints, examples or links? Shouldn't be too hard. ngspice seems to have no limit to the length of a PWL spec. Put the audio in some simple form (like raw binary samples), write a tiny program to convert to PWL. Generate output with .PRINT, write another tiny program to convert to binary samples. 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
Re: gEDA-user: Speaker SPICE modeling with gschem and ng-spice/gnucap
On Mon, Sep 12, 2011 at 2:39 PM, John Doty j...@noqsi.com wrote: On Sep 12, 2011, at 3:09 PM, Hannu Vuolasaho wrote: I have been playing with one guitar amplifier project for a while and so far the amplifier design has been more or less copy and paste and simulate and guess from graphs. However I bumped in net this blog post http://nordicnerd.blogspot.com/2011/08/active-speakers-spice-with-actual-audio.html Is it possible to do same thing? Input wav to simulator and get speaker's output and hear it? I know it's not perfect but it could be very helpful. Has someone done this before and provide some hints, examples or links? Shouldn't be too hard. ngspice seems to have no limit to the length of a PWL spec. Put the audio in some simple form (like raw binary samples), write a tiny program to convert to PWL. Generate output with .PRINT, write another tiny program to convert to binary samples. Here's the spice raw reader that jpd and Hannu are both missing out on: http://www.h-renrew.de/h/python_spice/spicedata.html Even outputs to hdf5: http://www.hdfgroup.org/HDF5/ You'd probably be able to glue together the spice raw reader and this fairly quickly to get wav output from ngspice: http://www.ar.media.kyoto-u.ac.jp/members/david/softwares/audiolab/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reasons for wikibook (was: plugins)
Am 12.09.2011 um 16:43 schrieb DJ Delorie: 1. The easier it is to contribute, the more likely you are to be vandalized. Wikipedia has seen plenty of this problem. You need some method of authorizing trusted contributors and approving changes by others. As a heavy user of another technical wiki I can report this doesn't happen there. Wikipedia is a special thing in that matter, because it's a lot about opinions and politics. In a technical wiki you're glad to get a few edits each day and as typically the page creator maintains a page, it's easy to review edits. The only difficult thing here is to accept edits, even if you'd have it written differently. Heavy re-editing and deleting contributions makes people go away quickly, so don't do this but add your view as well. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: reasons for wikibook (was: plugins)
On Tue, Sep 13, 2011 at 8:59 AM, Markus Hitter m...@jump-ing.de wrote: Am 12.09.2011 um 16:43 schrieb DJ Delorie: 1. The easier it is to contribute, the more likely you are to be vandalized. Wikipedia has seen plenty of this problem. You need some method of authorizing trusted contributors and approving changes by others. As a heavy user of another technical wiki I can report this doesn't happen there. Wikipedia is a special thing in that matter, because it's a lot about opinions and politics. +1 I think it unlikely that a gEDA wiki would be targeted. I think wikimedia keeps a history so it may be trivial to restore an older version in the event someone does vandalise a page. If creating login is not a huge overhead then just disable anonymous edits - that way there is a degree of ownership of any changes to content. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: plugins (was: How can you help...)
DJ Delorie wrote: I still have to decide, where to start. An overview? A getting started? A HOWTO? A table of contents to be filled? Based on what kinds of questions I tend to answer in irc and email, I think the relative priority should be: * Introductory tutorials that demonstrate the most common flows, IMHO, this should not be plural. That is, a getting started should decide for one work-flow and stick with it. A reader should not feel the necessity to decide between options before he/she can grasp the consequences. On the other hand, the flexibilities should not be completely hidden, either. How about this: Redo the toy task of the getting-started with different work-flows. showing off the most current and I'd say, tutorials are not a place to show off, but to teach. (Mayby I am overly picky with words...) newbie-friendly ways of using the tools. ^^^ Here comes the hard part: What exactly is newbie-friendly? Is it a step-by-step walk through a minimum manual set-up of a project? Or is a scripted set-up wich results in a full fledged project dir complete with local configs and makefiles? Both have their pros and cons. * How-to's for tasks which are less common, showing off the toolkit features. I like to imagine this in the form of show-casing real world projects which demonstrate how specific tasks can be achieved. Ideally, the show-cases would include source files at different stages. Topics for advanced use: * drawing symbols * creating footprints manually on PCB canvas * creating footprints with the various generators * scripted printing * use of makefiles * a self contained project dir * simple hierarchy * hierarchy with sub sheets used several times * layout with repetative portions * source control with git Additional items: * A vademecum of keyboard accels, actions, file formats and important command line options. This is kind of a reference manual light. * the history of geda, gaf, pcb, etc. * getting started with simulation (unfortunately, I am a complete noob for this) * Replacements for the reference manuals. Reference manuals should be comprehensive, accurate and reflect the status of a specific version. Overall style and readability are less a concern. This calls for tight coupling to the source and inclusion in the make tool chain. The concept of collaborative online editing does not mix well with such a scripted approach. It is part of the source and should be treated as such. * Internals docs for new developers. This is clearly a task for core developers and way beyond the scope of what I intend to start. Anyway, I wouldn't sort the priority of these documents in any specific order. All of them are vital for the project -- each in a different way. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 Moderation of geda-user seems to be lifted, lately. I am still unhappy with it. Why? Because it is completely nontransparent. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: plugins (was: How can you help...)
IMHO, this should not be plural. That is, a getting started should decide for one work-flow and stick with it. As John points out, there's more to geda than making circuit boards. So, tutorials for schematics-pcb, schematics-sim, verilog-sim, etc. Then, within each case, beginner vs advanced, like one schematic to a two-layer board, then multiple schematics, then heirarchical to many-layer with BOM and gerber, etc. showing off the most current and I'd say, tutorials are not a place to show off, but to teach. (Mayby I am overly picky with words...) I meant, for example, using PCB's importer instead of gsch2pcb, or snapshots of the GTK interface instead of the ancient Xaw one. newbie-friendly ways of using the tools. ^^^ Here comes the hard part: What exactly is newbie-friendly? To me, this means if you've never used gEDA before. I like to assume that anyone attempting to do EDA already has some electronics background and is familiar with their computer's OS, but hasn't touched EDA yet. The kinds of advanced techniques we talk about in the geda-user list is not something I want to expose a new user to until they understand the basic functionality of the toolchain as a whole. Is it a step-by-step walk through a minimum manual set-up of a project? Or is a scripted set-up wich results in a full fledged project dir complete with local configs and makefiles? Both have their pros and cons. I like to use toy designs that demonstrate the techniques, and leave it up to the user to apply those techniques to more complex designs. See http://www.delorie.com/pcb/docs/gs/gs.html#Your-First-Board At this stage, the tutorial should be end-to-end so that the user gets a sense of accomplishing something without the frustration of the big learning curve. * Replacements for the reference manuals. Reference manuals should be comprehensive, accurate and reflect the status of a specific version. Overall style and readability are less a concern. This calls for tight coupling to the source and inclusion in the make tool chain. The concept of collaborative online editing does not mix well with such a scripted approach. It is part of the source and should be treated as such. IMHO it needs more than just a source extraction. There's some overview information that needs to be in there - the WHY of everything, not just the WHAT. * Internals docs for new developers. This is clearly a task for core developers and way beyond the scope of what I intend to start. Yup. Don't worry about it, just keep in mind that it'll be out there at some point. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
