Mail Archives: geda-user/2012/10/28/07:54:07
On Oct 28, 2012, at 2:13 AM, Bert Timmerman wrote:
> You hit this nail spot on the head: it's all about momentum and how the software is perceived at first glance ... "you never get a second chance for a first impression".
>
> Fritzing does that with integration of a schematic capture + breadboard + PCB layout UI,
>
> KiCad does that with integration of schematic capture + PCB layout + 3D views and models,
>
> Eagle does integration of schematic capture and PCB layout UI,
>
> gEDA-tools do that with ... letting the user find his way in a maze of dispersed tools.
gEDA enables the skilled user to do things far beyond the capabilities of the tools you mention. Symbolic circuit analysis, (with the help of Mathematica), VLSI design (with the help of other tools), or feed ~20 different PCB layout programs. Instead of wasting time with GUI, the gEDA user can automate document and data product generation by employing other tools like make and LaTeX.
>
> And a for user convienence www.symbols.org, only usable by fighting and conquering CVS (the SCM tool you will learn to hate).
It's browsable by web, so consumers don't need CVS. And CVS isn't that hard.
>
> So the gEDA-tools need to look "sexy" and needs more "eye-candy" to get this "sexy" tool-set to flirt with new (candidate) users.
Nah, let 'em come when they figure out that the other tools can't get the job done. Then they'll actually appreciate gEDA.
>
> So what could gEDA-devs do to catch those "drive-by" users, a possible road map follows here:
>
> 0.
> Get the GUIs consistent with each other.
>
> 1.
> Pull in xgsch2pcb as a first point of entry, squash any bugs left and implement outstanding feature request.
> First step into integration, still keeping a use case for every single tool ;-)
Shudder. If gEDA was focused on serving pcb, I wouldn't be here. What's the point of that? The tools above are likely to remain superior to the gEDA->pcb flow. gEDA's strength is all the *other* stuff it can do. Please do not let the weaknesses of pcb be the driving motivation for changes to the gEDA toolkit.
>
> 2.
> Now we are building an "integrated tool", maybe add something like "xgsch2gnucap" in to xgsch2pcb.
Why gnucap? Why not ngspice? Or any of the other simulators out there? We can export files to many (maybe even most) of them now. The area where we can improve is in the export scripts. See https://github.com/noqsi/gnet-spice-noqsi for work in progress there.
> In that case, changing the name to "gEDA-tools" follows suit.
> The addition could look like ktechlab or maybe even something smarter.
>
> 3.
> Integrate gattrib into gschem.
> IMO there is no use case for a stand alone usage.
Just because you don't see one doesn't mean there couldn't be one. What about serving other tools that generate .sch files? lambda-geda, pins2gsch, etc.? Will gschem be the only .sch editor forever? I hope not. Also keeping the tools separate has kept gattrib's bugs out of gschem, and that's a good thing. There are few sensible "use cases" for gattrib anyway, as far as I'm concerned. It's a "touch up brush" for little jobs, not a power tool. Keeping tools simple and focused is a good thing.
> AFAICT it started when SDB scratched his own itch, and when that itch was gone ...
>
> 4.
> Start up/migrate www.gedasymbols.org to git and get "social integration" (like in Github) on those symbols, footprints, gnucap models, scripts and other related stuff
> Give users a chance to improve on other users stuff with "pull requests" and "issues".
> Give new users a chance to start with a fork of known good stuff that really works.
> Maybe even move over to Github with the gedasymbols.org repo and let this organization handle the maintenance load.
Git's a massive kit of power tools. I'm puzzled that you think that those users who reject the toolkit approach for EDA will be able to embrace Git.
>
> 5.
> Get 3D modeling "implemented" in pcb, either by choosing for blender or any other real modeling application, or choose for something like VRML (not a very smart output format for post processing, it's like serving a pdf/ps file).
> I started with both an OpenSCAD and a DXF exporter (pre-alpha stage, not finished yet), other exporters can follow for other file formats.
> Maybe the usage of plug-ins is a better choice here for reducing the maintenance load on developers.
>
> 6.
> One developer can adopt a piece of the code base as suggested in some earlier post, and let it be known which part is adopted !!!
> So patches/diffs can be directed to the right developer and do not fall into a "LaunchPit of doom" where nobody does what anybody could have done in an in between hour, or so ;-).
Better for developers to work on new tools for the kit, rather than damaging the existing tools because they don't understand the breadth of all their uses.
>
> 7.
> Add a Breadboard GUI/tool for it is a possible next step in workflow after simulation (Gnucap) is done, and more often than not, done before layout time.
> Here we have a gap in our workflow which is not supported by gEDA (yet).
>
> 8.
> Please do fix the gem called toporouter !!!
> Here is some "eyecandy" in the category "must have", for it differentiates pcb from the "competition".
> We would seriously "loose" advantage by leaving it to others to pick this one up and integrate it into their stuff.
> Eventually the competition will integrate (with the proper authors of the toporouter code base mentioned of course, the GPL & FSF will see to that), but for now we should cherish this "leading edge".
>
> 9.
> In the mean time grab as many "drive-by" contributors of patches/diffs as you can get a hold on, lure them into making another contribution.
> Everything is allowed, just think up something.
How about a .sch *plugin* for pcb? That would scratch the itch that you seem to have for an integrated tool without getting in the way of other flows.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -