Mail Archives: geda-user/2015/07/15/21:53:23
> > If it *really* bothers you, it's all open source - make a copy for
> > yourself and don't update, and you don't have to worry about anything
> > changing any more.
>
> How can you do collaborative work that way? I reject the idea that
> gEDA is only for hermits.
If you don't want change, you're not collaborating any more. You're
just using. Of course I'm talking about collaborating on gEDA
development, not collaborating on projects using gEDA. If you're
talking about the latter, you can just share whatever copy of gEDA
you're using with whoever you're collaborating with, if needed.
> How do you keep the documentation and menus simple? Every
> unnecessary feature makes it harder for the user to discover and
> employ the necessary ones (been there with Viewlogic).
The documentation and menus are already not simple. They don't even
follow good UI design, or the standards for how UIs should be
organized to help new users adapt. And, by definition, *every*
feature of EDA is "unnecessary" since the whole point of EDA is to
make it easier for the user to do a job that had been done in the past
without EDA tools.
So where do you draw the line?
In this case, we shouldn't. We should review each feature separately,
and judge it and its implementation on its own merits, instead of
pre-judging them or dismissing them categorically.
> How do you avoid interaction between features? Integration is the
> enemy here, but the toolkit approach is a great way to encourage
> factoring.
Integrating vs factoring, either at the source level or at the command
line level, is neither good nor evil. It's either well designed or
poorly designed, and either approach has its risks and rewards. A
tightly integrated but internally factored app could be well designed
and easy to safely extend; a large set of simple programs could be
poorly designed and hard to use together or understand. Or the other
way. In either case, the right thing to do is to let someone come up
with a design *first*, and *then* discuss the risks and rewards.
Discouraging them *before* they have a chance to demonstrate their
idea is counterproductive.
> > or being needlessly complex. The opposition to *any* change has made
> > this more difficult than it should be.
>
> No, it *should* be difficult. Geda-gaf is a mature, stable, useful
> toolkit. Ill-considered change is bad. Adding features to software
> is like adding mass to aircraft: not always bad, but there'd better
> be very strong justification.
Please avoid the arbitrary analogies and generalizations. "Adding
features to software is like adding flavors to ice cream; if the users
want it, you should do it." See? I can make them up too, but they
add nothing to a technical discussion of the merits of the specific
features.
Ill-considered *anything* is bad, that includes ill-considered
stagnation.
> But that itself reflects pcb's inflexibility. If you could import
> netlists from 20 other tools, you'd want those interfaces factored
> out, I think. I certainly would.
There's your negativity again. I *did* factor out the interface, and
pcb *could* import from 20 other tools, if anyone wants to write the
appropriate netlister scripts for those other tools.
- Raw text -