X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <508CF6D9.5000908@xs4all.nl> Date: Sun, 28 Oct 2012 10:11:53 +0100 From: Bert Timmerman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: Re: [geda-user] The state of gEDA/gaf (Was gEDA/PCBs diversity, Was: Pin hole size) References: <2CB304B5-9587-4734-84E4-49F464744D11 AT noqsi DOT com>

<6BF2E986-51EB-41E9-A4AD-8071CD00B1A1 AT jump-ing DOT de> <834283D4-0891-486E-A981-2FF20B32C615 AT noqsi DOT com> <54CAA7EE-7638-4B89-8197-111D0493F859 AT noqsi DOT com> <508CE947 DOT 4050408 AT xs4all DOT nl> In-Reply-To: <508CE947.4050408@xs4all.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Reply-To: geda-user AT delorie DOT com Bert Timmerman wrote: > Markus Hitter wrote: >> >> Am 27.10.2012 um 01:36 schrieb John Doty: >> >>> On Oct 26, 2012, at 4:51 PM, Markus Hitter wrote: >>>> >>>> Fritzing doesn't even try to be as detailed as gEDA. But Fritzing >>>> gets all the newbies, so in the end, Fritzing wins. Simple maths. >>> >>> Why is that winning? As far as I'm concerned, the tool that gets the >>> job done wins. >> >> Fritzing wins, because those people doing their first projects with >> Fritzing will never even try with gEDA. And if they do, they'll run >> away the same minute, because they can't even rotate an item. That >> simple. >> >> And yes, I've seen that many times. gEDAs awkward user interface / >> mouse button mapping / inconsistent behaviour is about the biggest >> complaint I receive when asking people to participate in projects I >> maintain. >> >>> A fine example of the problem is LyX, ... >> >> And because LyX made a mistake you assume gEDA inevitably has to make >> the same mistake? For my part, I consider gEDA developers to be more >> intelligent. So far I'm proven right, for example the direct >> schematics import, which is a step of integration, works without >> hobbling script users. >> >>>> Who exactly is interested in the history of a tool? I use it today >>>> and I couldn't care less by whom and how it was used five years ago. >>> >>> Well, I *do* care about that kind of consistency. Aerospace projects >>> take a long time, and I have a decade of gEDA schematics that I reuse. >> >> Again you do the assumption modernizing the user interface would make >> your older designs unusable. There's no reason for this assumption. >> The mapping of mouse buttons is 100% independent from the file >> format. The file format is also 100% independent from the size of the >> window used for viewing it or wether this window is shared for both, >> gschem and pcb. >> >>> It's less likely that a transcendental genius will appear who can >>> accomplish what I think you want step by step, fighting the >>> architecture and legacy flows all the way. >> >> Same as above. Assumptions without substance. Nobody is fighting >> working with legacy data. >> >> In fact, the introduction of holes in polygons has brought us >> compatibility with older file formats. Before, files were tagged with >> a 2010something version number, now designs without polygon holes are >> flagged with version 20070407. >> >> There you go. A new feature actually *increased* compatibility with >> legacy stuff. >> >> >> Markus >> >> - - - - - - - - - - - - - - - - - - - >> Dipl. Ing. (FH) Markus Hitter >> http://www.jump-ing.de/ >> >> >> >> >> >> > Markus, > > 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. > > And a for user convienence www.symbols.org, only usable by fighting > and conquering CVS (the SCM tool you will learn to hate). > > 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. > > 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 ;-) > > 2. > Now we are building an "integrated tool", maybe add something like > "xgsch2gnucap" in to xgsch2pcb. > 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. > 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. > > 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 ;-). > > 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. > > Just my EUR 0.02 on the subject. > > Kind regards, > > Bert Timmerman. > Hi all, Just to clearify: Ad 0. IMO GUIs in the gEDA-tool set should be consistent "out of the box" for new users (principle of least surprise) on a system level (in $PREFIX/share/geda, $PREFIX/share/pcb, $PREFIX/share/xgsch2pcb, or $PREFIX/share/whatever). If users would like to keep their legacy keybindings and shortcuts for every tool different than that should be configurable on a user level (in $HOME) or on a per project directory basis (different projects may have different needs). Kind regards, Bert Timmerman.