Mail Archives: geda-user/2012/10/28/05:12:22
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.
- Raw text -