Mail Archives: geda-user/2015/08/25/13:47:37.1
On Tue, 25 Aug 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Tue, Aug 25, 2015 at 11:36 AM, myken <myken AT iae DOT nl> wrote:
>> On 25/08/15 16:51, Evan Foss (evanfoss AT gmail DOT com) [via
>> geda-user AT delorie DOT com] wrote:
>>
>> On Tue, Aug 25, 2015 at 10:17 AM, myken <myken AT iae DOT nl> wrote:
>>
>> On 25/08/15 15:18, John Doty wrote:
>>
>> Isn't the whole idea in this thread "let's make gschem/pcb more accessible??
>>
>> Yes, but the answer looks *completely* different depending on whether you?re
>> coming from a pcb (integrated tool) or geda-gaf (toolkit) perspective.
>>
>>
>> It must be my lack of understanding the English language but I don't think
>> there is anyone on this list disputing the power, flexibility, simplicity
>> and usability of the geda-gaf (gschem) toolkit. Well I don't.
>> If I understand what I have read there is no one that wants to restrict the
>> functionality of gschem.
>> If anything I guess there is a bigger change that pcb will move towards
>> gschem (geda) then the other way around.
>>
>> The PCB developers are the current majority.
>>
>> Maybe, but that doesn't automatically mean the gschem (geda) architecture
>> will change!
>> I use geda-gaf for schematic entry, simulation, VHDL design and PCB design.
>> It is a great tool, just the way it is. I don't want it to change.
>> But I do see a great benefit in a more accessible toolkit (including pcb).
>> If that means adding an additional button in the menu bar, so be it.
>>
>> All people try to do is find a way to make the combination more accessible.
>> I don't mind adding the restriction "looking from the geda-gaf perspective",
>> if that makes us move forward.
>>
>> gschem needs a more viable plugin interface so that people can
>> implement their desired gschem and pcb relationship with out
>> subjecting the rest of us too it.
>>
>> Sound great to me. Anyone opposes this? Can we move forward from here?
>
>
> I think in that objectives thread a while back we agreed that adding
> other plugin interfaces in parallel to scheme was a good thing. The
> best way to do it would be via (gpmi) the same library Igor2 used in
> pcb-rnd. That way we don't add any additional dependencies and debug
> will be easier. One thing that would have to be worked out is how to
> block gpmi from passing scheme along since it also supports that
> language. We don't want to unintentionally gain an extra scheme
That's not hard: gpmi is not doing anything by itself, you always
explicitly request things. Your C code requests gpmi to load a module that
interprets a language and your C code requests gpmi to run some code in
it. If you just don't load the guile module and you ask it to run scheme
code for you, it won't.
Btw, from your C code, you don't see any difference between
scripting languages, you see an unified, simplified (and not very CPU
efficient) interface. So after all, it doesn't even matter if you
don't block your user from using scheme through gpmi, as it has no chance
mixing with the scheme context used by gschem.
Regards,
Igor2
- Raw text -