kicad-developers team mailing list archive

["phinitnan_c" <crackerizer@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, "Lorenzo" <lomarcan@...> wrote:
>
> 
> 
> --- In kicad-devel@xxxxxxxxxxxxxxx, "phinitnan_c" <crackerizer@> wrote:
> > Please note that I don't really care what implemenation will be used aslong 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 importance 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 category?
> 
> 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 berkeley db or a sqlite format. At least keep a text import/export format (like the 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 timer (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 themdirectly 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 scheme (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 somethinglike mcu-atmel or mcu-microchip for category.

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.