X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 5 Jan 2016 00:56:09 +0100 (CET) From: Roland Lutz To: geda-user AT delorie DOT com Subject: Re: [geda-user] should we broaden scope of libgeda In-Reply-To: <1A92FF68-AF05-4246-BB7B-608532787970@noqsi.com> Message-ID: References: <20160102091556 DOT BBC6D809D79B AT turkos DOT aspodata DOT se> <20160102190222 DOT 63BE6809D79B AT turkos DOT aspodata DOT se> <20160102205101 DOT 327B9809D79C AT turkos DOT aspodata DOT se> <1A92FF68-AF05-4246-BB7B-608532787970 AT noqsi DOT com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-987513197-1451949357=:1432" Content-ID: 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-987513197-1451949357=:1432 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Mon, 4 Jan 2016, John Doty wrote: >> As far as gEDA/gaf is concerned, the logical next step would be to have >> gschem use the Xorn data structures and storage library. > > No, please, no. Make a new xornschem. This is an opportunity to > modernize the GUI, too. But please donąt make drastic changes in how > existing production code works. This isn't about the GUI at all. The existing code works in excruciatingly spaghettine ways which make improvements like Igor2's back-annotation much more complicated than necessary. The changes I suggested should, if done correctly, not change the existing user experience in any way. However, they would make accessing the application's behavior on an intermediate level (more internal than Guile scripts can access, but higher than C code) much easier than before. I see your point about not breaking existing workflows, and I realize I might have not been conservative enough about that in the past. However, this should not mean that we can't ever change the programs' internals; it just means we should be very careful when doing so. --8323329-987513197-1451949357=:1432--