MIME-Version: 1.0
In-Reply-To: <20150205191917.Horde.7a_VPZBao09SQOYA9sJOhA9@webmail.in-berlin.de>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1502050732080 DOT 7324 AT igor2priv>
	<20150205191917 DOT Horde DOT 7a_VPZBao09SQOYA9sJOhA9 AT webmail DOT in-berlin DOT de>
Date: Fri, 6 Feb 2015 02:24:10 -0500
Message-ID: <CAM2RGhTV5rYiqXbdO7djLP09mPtUuhCC3X=tFF_xK0a0Q8A1+w@mail.gmail.com>
Subject: Re: [geda-user] FOSDEM/edacore - preferences on file format, language
From: Evan Foss <evanfoss AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: text/plain; charset=UTF-8
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

I like the way Igor2 broke down the issue. A lot of this is stuff that
has been kicked around this list before but you never know maybe this
time some of it will stick. I strongly agree with the 1st topic (file
formats). I feel like we already have that. On the 2nd I am weary of
databases but I could be convinced they are a good thing. I could
debate 5 but I think the other thread has skewed the ratio of
debate/hotair enough for one email list already.

The other thread has the slides from the talk. Although for some
reason it continues to debate language. gEDA is in C and KiCad is in
C++. As far as I can tell the intention of edacore talk as to get
people writing a library or libraries in C/C++ to do the conversion
vendor data into formats we could use in gEDA/KiCad. I get that
everyone likes the idea of plugins but this sounds like a bunch of
smaller tools in C/C++ that for gEDA we distribute in parallel to
gschem, pcb, gattrib and etc. The need for a another language to write
plugins is lost on me.

We need the ability to pull in data from vendor models and
autogenerate symbols, footprints and etc which is what the talk was
about (going by the slides). As I see it the things we need are in the
glue Igor2 mentioned in the 2nd topic. I would really like it if there
was a small set of utilities that let us move our work from gEDA to
KiCad and back again with out degradation or frustration. Of course
for that to work I think we would have to move back to the model of
packaging libgeda separately from the rest of gaf but the important
part is that someone writes the code first. I am unsure of how easy it
would be to split off the underlying libraries from KiCad's main
program into a separate package.


On Thu, Feb 5, 2015 at 1:19 PM, Hagen SANKOWSKI
<hsank AT nospam DOT chipforge DOT org> wrote:
> Hello igor2.
>
> Quoting gedau AT igor2 DOT repo DOT hu:
>
>> 1. File format: [snip]
>
>
>> 2. database, lib, groupping: [snip]
>
>
>> 3. Symbols, footprints... and glue! [snip]
>
>
>> 5. design for filters: [snip]
>
>
> Thanks, well figured out!
>
> Regards,
> Hagen Sankowski
>
>
> --
> "They who can give up essential liberty to obtain a little temporary
> safety, deserve neither liberty nor safety." Benjamin Franklin (1775)
>


-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/