Mail Archives: geda-user/2015/07/15/23:06:39
On Jul 15, 2015, at 7:53 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>>> 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.
I’m collaborating on the design of circuits. That’s the point, isn’t it? Or is this just software for software’s sake?
> You're
> just using. Of course I'm talking about collaborating on gEDA
> development, not collaborating on projects using gEDA.
I have collaborated on gEDA development (the attribute censorship bug fix for example). That was Kai-Martin’s peeve, not so much mine, but Bas suggested a (partial) fix, and I contributed the Scheme to finish it (and then had it hacked apart by other developers, so it didn’t actually fix the bug, but that’s a long story I have no interest in telling in detail).
I’ve also tried to improve the gnetlist documentation so that others could collaborate by contributing back ends. That’s development I will never oppose.
> 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.
They run different distributions or different operating systems. Dealing with IT at a foreign university can be challenging.
>
>> 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.
True. They used to be better (that was an attraction to me). That’s not a good excuse for making them worse.
> They don't even
> follow good UI design, or the standards for how UIs should be
> organized to help new users adapt.
True. Very 1990’s. But that really requires a new schematic editor design: mutating gschem to make it contemporary would be chaos, I think.
> 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.
Oh, no. Features often make the job *harder*. Those are the unnecessary ones. Viewlogic was full of them. And just the last two weeks, I’ve been trying to do something very simple with Vivado. After gigabytes of download and days of debugging through a fog of features and marketer-speak pretending to be documentation, I can finally take a firmware file someone mailed to me and reflash the FPGA in my hardware.
>
> 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.
True, and I do not oppose the integrated approach. But an integrated tool would no longer be gEDA. There should be a place for both approaches, rather than a drive to turn toolkits into integrated tools.
If you want more integration, you should write a schematic plugin for PCB. You could get a consistent UI that way, too.
> 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.”
That’s marketer thinking. One nice thing about free software is that you don’t have to do that. Nobody adds features to TeX (but they keep developing add-on packages).
> 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,
You and I have a different notion of what a factored toolkit is.
> and
> pcb *could* import from 20 other tools, if anyone wants to write the
> appropriate netlister scripts for those other tools.
>
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -