X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] The new to do From: John Doty In-Reply-To: <201507160153.t6G1rD3Q016240@envy.delorie.com> Date: Wed, 15 Jul 2015 21:06:13 -0600 Message-Id: <96883A7C-A0CF-43BF-B787-9D17BD9BC47F@noqsi.com> References: <55A2A0A2 DOT 4080403 AT ecosensory DOT com> <7AE39440-DA68-4491-A965-C1B97D1D86C1 AT sbcglobal DOT net> <20150712213152 DOT 7968b74c AT jive DOT levalinux DOT org> <304D9D86-3CF6-4D61-A5CA-6CE414EA0661 AT sbcglobal DOT net> <20150712224637 DOT 2d4cc2de AT wind DOT levalinux DOT org> <55A2E9B7 DOT 9040502 AT neurotica DOT com> <20150713131707 DOT GA782 AT recycle DOT lbl DOT gov> <55A4042E DOT 5060402 AT neurotica DOT com> <55A41B30 DOT 50602 AT neurotica DOT com> <254F9AFE-1A3E-4D88-BABF-E6E0F87A56B1 AT icloud DOT com> <1436960577 DOT 1072 DOT 6 DOT camel AT ssalewski DOT de> <201507151820 DOT t6FIKYME001704 AT envy DOT delorie DOT com> <201507152007 DOT t6FK7lv8005229 AT envy DOT del! ! orie.com> <24AD56C6-B7C2-4D7E-B69A-F68DBACCBFDC AT noqsi DOT com> <201507152051 DOT t6FKp8ip006830 AT envy DOT delorie DOT com> <201507160024 DOT t6G0OZrG013557 AT envy DOT delorie DOT com> <201507160153 DOT t6G1rD3Q016240 AT envy DOT delorie DOT com> To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t6G36Nf3025613 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Jul 15, 2015, at 7:53 PM, DJ Delorie 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