delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2012/10/28/04:15:03

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <508CE947.4050408@xs4all.nl>
Date: Sun, 28 Oct 2012 09:13:59 +0100
From: Bert Timmerman <bert DOT timmerman AT xs4all DOT nl>
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: <CANqhZFxYH+Y5U1ai7ey-s+4nz6eYDM2vx3aMDb7WuigNXmi4AQ AT mail DOT gmail DOT com> <2CB304B5-9587-4734-84E4-49F464744D11 AT noqsi DOT com> <CANqhZFwPNG4R1dR2X0HB+tP1JzNXUAVg55gy54Lry5E49aAQ6Q AT mail DOT gmail DOT com> <E9D200C7-475C-4CC7-A592-5A6C14B3EA25 AT noqsi DOT com> <6BF2E986-51EB-41E9-A4AD-8071CD00B1A1 AT jump-ing DOT de> <834283D4-0891-486E-A981-2FF20B32C615 AT noqsi DOT com> <C3C35AF4-24D1-4977-9134-2C0B13473D01 AT jump-ing DOT de> <54CAA7EE-7638-4B89-8197-111D0493F859 AT noqsi DOT com> <D59D8F6D-0436-4A8D-AFC0-5124BD3031D6 AT jump-ing DOT de>
In-Reply-To: <D59D8F6D-0436-4A8D-AFC0-5124BD3031D6@jump-ing.de>
X-Virus-Scanned: by XS4ALL Virus Scanner
Reply-To: geda-user AT delorie DOT com

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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019