X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 2 Jan 2016 19:41:50 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] should we broaden scope of libgeda
In-Reply-To: <CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1601021922530.4119@newt>
References: <20160102091556 DOT BBC6D809D79B AT turkos DOT aspodata DOT se> <CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg AT mail DOT gmail DOT com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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, 2 Jan 2016, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote:
> On 2 Jan 2016 09:18, <karl AT aspodata DOT se> wrote:
> > Wouldn't it make sense to move things (that isn't related to a gui)
> > from gschem to libgeda ?

It's more the other way round--libgeda contains many things which are 
related to the GUI and should be moved to gschem.  IMHO, it would make 
most sense to pull the general-purpose and gnetlist-related functionality 
out of libgeda and merge the remaining code back to gschem.

> whilst I'd concede there might be cases for moving certain code one way 
> or the other, I think a more formalised separation of libraries and ui 
> programs is good. It just depends on logical separation, and potential 
> reuse cases.

This is what I intend with Xorn (see my post "What Xorn does, and why it 
does it like that").  The idea is to move the relevant functionality of 
gEDA into a set of libraries and have the GUI programs basically be 
frontends to these.

> It could start to allow a framework where we use plugins that apply some 
> of the semantic attribute meanings at a point shared between the tools. 
> (Meaning you can have smarter behaviours in gschem whilst those workflow 
> specific plugins are loaded). I would love to see things like slotting 
> move to being a plugin, for example.

You might want to have a look at the pp_*.py files in 
xorn/src/python/geda/netlist.  When refactoring the netlister, I moved all 
code related to an optional feature (slotting, hierarchy, the graphical= 
and net= attributes) to a single file which is called from the main 
netlisting function to post-process the netlist.  When using a custom 
netlisting pipeline, you could just skip these function calls or replace 
them with something else.

> gnetlist should continue to function and look the same to the outside 
> world, but code wise - may end up much simpler, probably just providing 
> a invocation wrapper around the backend scheme code.

This is how "xorn netlist" works. :-)