Mail Archives: geda-user/2015/08/25/19:36:02
--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] <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] <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] <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
<div dir=3D"ltr"><div>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.</div><div>=C2=A0</div><div=
>If a planned new footprint or file format is unlikely to be easily readabl=
e or editable by humans, then</div><div>=C2=A0</div><div>1) the cleverer th=
e footprint creation tool will have to be to entice new users,</div><div>2)=
the more seamless the footprint importing options,</div><div>3) and the be=
tter the available default "essential" libraries will need to be =
to reduce the learning curve for new users</div><div>=C2=A0</div><div>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.</div><div>=C2=A0</div><div>Erich.</div><div>=
=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Wed, Aug 26, 2015 at 7:28 AM, Britton Kerin (<a href=3D"mailto:britton.=
kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-u=
ser AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=
=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Aug 25, 2015=
at 1:02 PM, Evan Foss (<a href=3D"mailto:evanfoss AT gmail DOT com">evanfoss AT gmai=
l.com</a>) [via<br>
<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <<a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> wrote:<=
br>
> On Tue, Aug 25, 2015 at 4:37 PM, Peter Stuge (<a href=3D"mailto:peter@=
stuge.se">peter AT stuge DOT se</a>) [via<br>
> <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] &l=
t;<a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>> wr=
ote:<br>
>> Evan Foss (<a href=3D"mailto:evanfoss AT gmail DOT com">evanfoss AT gmail DOT co=
m</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com<=
/a>] wrote:<br>
>>> The problem that has been consuming my mind or a few months no=
w is<br>
>>> how all of this should be represented in memory.<br>
>><br>
>> Linked lists. The overhead is small.<br>
><br>
> Yes but you want the lists to be meaningful. Just having a list of<br>
> elements on a layer is not enough. The way you store the info makes<br=
>
> moving footprints or moving traces more straight forward to implement.=
<br>
<br>
Igor is already moving things from script:<br>
<br>
=C2=A0 =C2=A0<a href=3D"http://repo.hu/projects/pcb-rnd/gpmi/rosetta/30_mov=
e/index.html" rel=3D"noreferrer" target=3D"_blank">http://repo.hu/projects/=
pcb-rnd/gpmi/rosetta/30_move/index.html</a><br>
<br>
I also really wish file format's could keep on being text.<br>
Internal SQL sure but I don't see the point of a not-human-readable<br>
format.=C2=A0 Its not<br>
as if the size or parsing time is likely to be significant.<br>
<br>
Now I'm going back to my strategy of not caring what happens to gEDA<br=
>
and just using my existing version.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Britton<br>
</font></span></blockquote></div><br></div>
--001a113d7fd669bc66051e2b312b--
- Raw text -