kicad-developers team mailing list archive

["SuperLou23" <superlou@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Vesa Solonen <vsolonen@...> wrote:
>
> ma, 2009-10-05 kello 23:35 +0000, Mateusz kirjoitti:
> >   
> > I would like to discuss about Vesa's questions
> > 
> > > and I'm also eager to take 'project librarian' position on best
> > effort
> > 
> > You have my vote! If it is taken into consideration ;)
> 
> I'm delighted to see that I've got accepted by you and Dick. I had such
> a feeling already as no loud opposition surfaced before ;) You guys did
> a nice ride sideways to web based library system and finally converged
> back to the topic. I almost got worried for a while. Anyway, ideas are
> fine, but we need to lay foundations first.
> 
> > > *Official symbol drawing guidelines with sizes and line widths.
> > 
> > http://users.tkk.fi/~vsolonen/kicad/Symbol_guidelines.txt - it is
> > good! But what about rules for drawing ICs?
> 
> IC part is a bit tricky, but I think it should use 'Outline' and 'Pin'
> class lines (at leas) and use 2DU corner to pin distance. Otherwise DU
> pin separation and 2DU or more between 'groups of pins'.
> 
> I'd like to get opinions how difficult it would be to implement such a
> line class system to eeschema library format and the parser. Is there
> anything else to add in on the same run to minimise changes? Finally it
> is up to implementer as usual, but this feature would make Kicad stand
> up from anything else by dynamic styling.
> 
> > I am always wondering what is the best way of pin positioning (eg.
> > grouping it due to role -> data, vcc, gnd together or just putting
> > them as they are in the package).
> 
> General purpose stuff should use functional grouping, but special
> purpose like TDA1572 could even use physical layout. This needs some
> case by case judging. 
> 
> > > *Discussion how to organise the library tree and possible
> > sub-branches.
> > 
> > I think that we should organize the tree due to manufacturer names
> > with some exceptions ( sometimes the chip is produced by more than one
> > company see 74xx, some memories, connectors etc.).
> 
> > > *Library and component naming policy
> > 
> > see above ...
> 
> I agree. The link I sent in the start had quite usable naming for pcbnew
> libraries and that's also very important to solve.
> 
> > > *Library licenses allowed.
> > 
> > Sorry, but I am not good in licenses ;(
> 
> The point is that Kicad must not end being another Eagle Lite with
> commercial restrictions. Not on the library either. For every
> contributor there should be authors file and changelog file entry and
> that should be all author needs for bragging rights ;) No ridiculous
> demands that $MYNAME is included on silkscreen layer... Some form of rip
> up protection may be needed. The particular license is up to discussion.
> I haven't yet studied the subject.
> 
> > The truth is that the library tree now is a tragedy! (I am using kicad
> > 20080825c from kubuntu 9.04 repository) 
> > 
> > Just look on "device" library. It is full of everything but what
> > schotky diode and mosfet has in common with speaker, jumper and bnc
> > connector?
> > 
> > Or why microcontrollers.lib is 90% duplicate of microchip.lib?\

Would anybody consider using tags instead of hierarchies? We could go backand forth on whether manufacturer should be the top of the tree or functionality, or we could allow both.

Or, as is likely the case in the real world of components, separate tag fields for manufacturer and functionality.

Unfortunately, from a little digging, I think it would take a pretty big rewrite of the component file spec and other tools to allow tagging in there without it being a hack. I do think (from my own experience) however that the old method of browsing folders for components should have died long ago. Filtering by tags and name in real time would make my life much easier (especially as the company parts db continues geting larger). I think there's a reason why autocomplete is very popular nowadays.

Just my 2 cents.


> > 
> > Don't you think it should be fixed by somebody?
> 
> That's what I'm making noise of :) Graphical tools for library
> reordering would be very nice, btw... I haven't yet decided how to do
> the task, but at least the task is clear.
> 
> -Vesa
>