X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=PGuLNmmRj2ws2ABn+7YC+ZoKUHHbqvtWul+rQhy6D6c=; b=g7rXMXVanNZZ2KuV59qZWFMG0q9dJDsBXhhgbN1+lBnBk3GuAZCh/ot1/vobTGqRru Sts827yiT0EKv3/GxbxzoXR4K9wmfTusz48jaSCyDMxYTAmB0GF72MVdqeqtKfGT2sIJ d5jc2Rs6e+2nkziftODYZphbD0fExBET96zGEF6ceZDntC2ugdH3sM0tHakwY8cDT4Ux 6jwMakjPgKEkQYlj9fiw8mTbZIszAXifTASrn36T0qvzQX4Kf7yIRGH1bb4SwpRxCTO2 e7jeiH/N271wg56bxCD4O3qEsGLeMh2xaUoBRPrZc9sYO6D4MZeO+/5PL0a2j+uIzvKi OCKA== X-Received: by 10.112.151.178 with SMTP id ur18mr3303846lbb.59.1436263995674; Tue, 07 Jul 2015 03:13:15 -0700 (PDT) Date: Tue, 7 Jul 2015 13:13:12 +0300 From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Subject: Re: [geda-user] libgeda3 Message-ID: <20150707101312.GB15599@localhost.localdomain> Mail-Followup-To: geda-user AT delorie DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 Sat, Jul 04, 2015 at 02:19:32PM +0200, Roland Lutz wrote: ... > The main difference between the libgeda3 and Xorn philosophies is that I'm > not trying to provide an API but a Python ecosystem in which different parts > of the code (e.g. upstream Xorn/gEDA and user code) interact natively. All > code is "part of" the ecosystem in some way, regardless of whether the user > has invoked it using one of the existing command-line programs or it has > been included by another application. ... > I think Xorn is the way to go for future gEDA development. Once I've > cleaned up the pythonized version of gnetlist, it could be included in > upstream gEDA, leaving gschem as the primary remaining user of libgeda. > Porting the smaller tools to Xorn shouldn't be a problem. Then libgeda, > with all its gschem-specific functionality, could be made a part of gschem > again. By having it use the Xorn primitives, code duplication could be > reduced, and gschem could be integrated with the rest of gEDA on a > schematic-manipulation basis. My point of view here is it would be better to forbear from high-level language wars. Some people like Scheme, others prefer Lua, Perl, Python and so on. We already use glib/gobject libraries within libgeda. Why not just use the possibilities they have. There are already bindings for several languages, e.g. for Python [1] and Guile [2]. The more complete list is at [3]. I probably don't quite understand your ecosystem approach since I've never had enough time to look through your code. However I realize that geda-gaf programs could be more tight bound if we'll use the extension approach vs embedding [4] (it is also interesting, what the author tells about using of multiple interpreters for one application). Anyway, users are already able to combine various programs together using the 'system' call. I think, some reasons why some developers prefer using API's instead of making program objects available to the user are described at [5]. [1] https://wiki.gnome.org/action/show/Projects/PyGObject [2] https://www.gnu.org/software/guile-gnome/docs/glib/html/ [3] https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK%2B [4] http://twistedmatrix.com/users/glyph/rant/extendit.html [5] http://www.gnu.org/software/libtool/manual/html_node/Library-tips.html Cheers, Vladimir