kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #03587
Re: Re: Gathering ideas of library and module
--001636c5be6ada8d8c0477b34fe2 Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 6, 2009 at 4:37 AM, phinitnan_c <crackerizer@...> wrote:
>
>
>
>
> --- In kicad-devel@xxxxxxxxxxxxxxx <kicad-devel%40yahoogroups.com>,
> "Lorenzo" <lomarcan@...> wrote:
> >
> >
> >
> > --- In kicad-devel@xxxxxxxxxxxxxxx <kicad-devel%40yahoogroups.com>,
> "phinitnan_c" <crackerizer@> wrote:
> > > Please note that I don't really care what implemenation will be used =
as
> long as it is best for the community. I just shared my experience with
> current implementation. File or database would be good if they are well
> designed. Let's move to the other issues. This issue might not be importa=
nce
> but I think it worth for discussion. Should library database be readable =
by
> human? and Is it possible to design the database to support better catego=
ry?
> >
> > My preferences:
> > 1) a current file-per-category seems adequate to me. And most (all?) of
> the competition does the same. Of course a good library manager would be
> useful
> > 2) Please keep the text format. I generated whole connector series with
> shell scripts, for example. I dare you to do the same with, i.e. a berkel=
ey
> db or a sqlite format. At least keep a text import/export format (like th=
e
> old orcad)
> > 3) More than a better category system maybe a better keyword system.
> Something like the firefox tag one.
> >
> > As for the 'catalogued by manufacturer' I think is not very viable...
> think about all the 'same part-different code', like the venerable 555 ti=
mer
> (I've seen the NE555, LM555 and XR555... probably there are yet more of
> these around :D)
> >
> > In my workflow I actually have a catalog of preferred parts and call th=
em
> directly by part number (resistors and capacitors are the exceptions...
> inductances usually are not:P) I.E. I don't pick a DIODE, I pick directly=
an
> ES2D, usually... said that you can get why I rarely use the lib browser:P
> >
>
> 1. Better category may not be necessary. We can use a better naming schem=
e
> (I think a folk here is working at it) for category.
>
> 2. Category is still needed. For example, we shouldn't put all available
> microcontrollers in a simple microcontroller category. We could use
> something like mcu-atmel or mcu-microchip for category.
>
If I understand the tagging points that were brought up earlier, we can
dodge the mcu-atmel vs. atmel-mcu holy war by tagging (or in this specific
case, seperate manufacturer and part fields).
ex: TMS320F28035
* Category: dsp, microcontroller
* Manufacturer: Texas Instruments
or TMS320F28035
* Tags: dsp, microcontroller, Texas Instruments
And instead of the traditional browsing folder paradigm (still possible by
sorting based on categories), we can shift to the "enter a few letters of a
tag to filter" paradigm.
>
> 3. I think storing library in an existing database engine is a good idea.
> We dont need to work on a new db engine, just concentrate at the library'=
s
> specification.
>
>=20=20
>
--001636c5be6ada8d8c0477b34fe2 Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<br><br>
<div class=3D"gmail_quote">On Fri, Nov 6, 2009 at 4:37 AM, phinitnan_c <spa=
n dir=3D"ltr"><<a href=3D"mailto:crackerizer@...";>crackerizer@gmai=
l.com</a>></span> wrote:<br>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div style=3D"BACKGROUND-COLOR: #fff"><span>=A0</span>=20
<div>
<div>
<div>
<p>
<div class=3D"im"><br><br>--- In <a href=3D"mailto:kicad-devel%40yahoogroup=
s.com" target=3D"_blank">kicad-devel@xxxxxxxxxxxxxxx</a>, "Lorenzo&quo=
t; <lomarcan@...> wrote:<br>><br>> <br>> <br>> --- In <a =
href=3D"mailto:kicad-devel%40yahoogroups.com"; target=3D"_blank">kicad-devel=
@yahoogroups.com</a>, "phinitnan_c" <crackerizer@> wrote:<b=
r>
> > Please note that I don't really care what implemenation will =
be used as long as it is best for the community. I just shared my experienc=
e with current implementation. File or database would be good if they are w=
ell designed. Let's move to the other issues. This issue might not be i=
mportance but I think it worth for discussion. Should library database be r=
eadable by human? and Is it possible to design the database to support bett=
er category?<br>
> <br>> My preferences:<br>> 1) a current file-per-category seems =
adequate to me. And most (all?) of the competition does the same. Of course=
a good library manager would be useful<br>> 2) Please keep the text for=
mat. I generated whole connector series with shell scripts, for example. I =
dare you to do the same with, i.e. a berkeley db or a sqlite format. At lea=
st keep a text import/export format (like the old orcad)<br>
> 3) More than a better category system maybe a better keyword system. S=
omething like the firefox tag one.<br>> <br>> As for the 'catalog=
ued by manufacturer' I think is not very viable... think about all the =
'same part-different code', like the venerable 555 timer (I've =
seen the NE555, LM555 and XR555... probably there are yet more of these aro=
und :D)<br>
> <br>> In my workflow I actually have a catalog of preferred parts a=
nd call them directly by part number (resistors and capacitors are the exce=
ptions... inductances usually are not:P) I.E. I don't pick a DIODE, I p=
ick directly an ES2D, usually... said that you can get why I rarely use the=
lib browser:P<br>
><br><br></div>1. Better category may not be necessary. We can use a bet=
ter naming scheme (I think a folk here is working at it) for category.<br><=
br>2. Category is still needed. For example, we shouldn't put all avail=
able microcontrollers in a simple microcontroller category. We could use so=
mething like mcu-atmel or mcu-microchip for category.<br>
</p></div></div></div></div></blockquote>
<div>=A0</div>
<div>If I understand the tagging points that were brought up earlier, we ca=
n dodge the mcu-atmel vs. atmel-mcu holy war by tagging (or in this specifi=
c case, seperate manufacturer and part fields).</div>
<div>=A0</div>
<div>ex: TMS320F28035</div>
<div>* Category: dsp, microcontroller</div>
<div>* Manufacturer: Texas Instruments</div>
<div>=A0</div>
<div>or TMS320F28035</div>
<div>* Tags: dsp, microcontroller, Texas Instruments</div>
<div>=A0</div>
<div>And instead of the traditional browsing folder paradigm (still possibl=
e by sorting based on categories), we can shift to the "enter a few le=
tters of a tag to filter" paradigm.</div>
<div>=A0</div>
<blockquote style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3D"gmail_quote">
<div style=3D"BACKGROUND-COLOR: #fff">
<div>
<div>
<div><br>3. I think storing library in an existing database engine is a goo=
d idea. We dont need to work on a new db engine, just concentrate at the li=
brary's specification.<br><br>
<p></p></div>
<div style=3D"MIN-HEIGHT: 0px; COLOR: #fff"></div></div></blockquote></div>=
<br>
--001636c5be6ada8d8c0477b34fe2--
References
