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=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=79kxfhZQuMaS6s7KR47tfDDXLYdIMaPR5PbxxVf7TC4=; b=Pz9GYTimax18ckP3d1RNVxapU3YUfyv6H9kO37fxv7Fqpugde5YFsEdVGqjsraSvmE 9KP7J1msNqLjIqyuk1D88leMreuidgkTj7q1+aU8thvm/uTLuwG+q0GKP3eZsq6K82l8 Iq/LpEi4G2BVmkT+GiS247FSUZLbHQAdFb9OfVUfxn/ZYR2yEl8+/ZJL6G9QCprV91Qr M7y7Zb2iMOTIU3YgoUo+6Rc+BzTnVsZtRODDA6mWS33fQP2HGvCLWAr9Z4J6I5G5tKcC cR8+ufFSYXuj8KU2cvnpduL+jtYZS2DlO54nDz6U3QTX6HeFmVwl3Lf2qBH5c9v1QtNr VIZg== MIME-Version: 1.0 X-Received: by 10.202.82.71 with SMTP id g68mr28370451oib.30.1440545744991; Tue, 25 Aug 2015 16:35:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Aug 2015 09:05:44 +0930 Message-ID: Subject: Re: [geda-user] SQL PCB file format From: "Erich Heinzle (a1039181 AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user Content-Type: multipart/alternative; boundary=001a113d7fd669bc66051e2b312b 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 --001a113d7fd669bc66051e2b312b Content-Type: text/plain; charset=UTF-8 Having the most elegent internal data representation of all the gEDA tools won't count for much if new users struggle to generate new footprints or import their existing ones because the new file format is not easily edited or understood any more. If a planned new footprint or file format is unlikely to be easily readable or editable by humans, then 1) the cleverer the footprint creation tool will have to be to entice new users, 2) the more seamless the footprint importing options, 3) and the better the available default "essential" libraries will need to be to reduce the learning curve for new users I'm just thinking out loud, but these usability issues should ideally be borne in mind if a new and improved format is being contemplated, to avoid putting off potential, new users. Erich. On Wed, Aug 26, 2015 at 7:28 AM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > On Tue, Aug 25, 2015 at 1:02 PM, Evan Foss (evanfoss AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote: > > On Tue, Aug 25, 2015 at 4:37 PM, Peter Stuge (peter AT stuge DOT se) [via > > geda-user AT delorie DOT com] wrote: > >> Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > >>> The problem that has been consuming my mind or a few months now is > >>> how all of this should be represented in memory. > >> > >> Linked lists. The overhead is small. > > > > Yes but you want the lists to be meaningful. Just having a list of > > elements on a layer is not enough. The way you store the info makes > > moving footprints or moving traces more straight forward to implement. > > Igor is already moving things from script: > > http://repo.hu/projects/pcb-rnd/gpmi/rosetta/30_move/index.html > > I also really wish file format's could keep on being text. > Internal SQL sure but I don't see the point of a not-human-readable > format. Its not > as if the size or parsing time is likely to be significant. > > Now I'm going back to my strategy of not caring what happens to gEDA > and just using my existing version. > > Britton > --001a113d7fd669bc66051e2b312b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Having the most elegent internal data representation = of all the gEDA tools won't count for much if new users struggle to gen= erate new footprints or import their existing ones because the new file for= mat is not easily edited or understood any more.
=C2=A0
If a planned new footprint or file format is unlikely to be easily readabl= e or editable by humans, then
=C2=A0
1) the cleverer th= e footprint creation tool will have to be to entice new users,
2)= the more seamless the footprint importing options,
3) and the be= tter the available default "essential" libraries will need to be = to reduce the learning curve for new users
=C2=A0
I'= ;m just thinking out loud, but these usability issues should ideally be bor= ne in mind if a new and improved format is being contemplated, to avoid put= ting off potential, new users.
=C2=A0
Erich.
= =C2=A0

On Wed, Aug 26, 2015 at 7:28 AM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
On Tue, Aug 25, 2015= at 1:02 PM, Evan Foss (evanfoss AT gmai= l.com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:<= br> > On Tue, Aug 25, 2015 at 4:37 PM, Peter Stuge (peter AT stuge DOT se) [via
> geda-user AT delorie DOT com] &l= t;geda-user AT delorie DOT com> wr= ote:
>> Evan Foss (evanfoss AT gmail DOT co= m) [via geda-user AT delorie DOT com<= /a>] wrote:
>>> The problem that has been consuming my mind or a few months no= w is
>>> how all of this should be represented in memory.
>>
>> Linked lists. The overhead is small.
>
> Yes but you want the lists to be meaningful. Just having a list of
> elements on a layer is not enough. The way you store the info makes > moving footprints or moving traces more straight forward to implement.=

Igor is already moving things from script:

=C2=A0 =C2=A0http://repo.hu/projects/= pcb-rnd/gpmi/rosetta/30_move/index.html

I also really wish file format's could keep on being text.
Internal SQL sure but I don't see the point of a not-human-readable
format.=C2=A0 Its not
as if the size or parsing time is likely to be significant.

Now I'm going back to my strategy of not caring what happens to gEDA and just using my existing version.

Britton

--001a113d7fd669bc66051e2b312b--