kicad-lib-committers team mailing list archive

[Carl Poirier <carl.poirier.2@xxxxxxxxx>]

> Maybe CamelCase would save some space. But Underscores would be nice
> to separate different types of information in the name. More, a dash could
> be used to seperate two following capital letters, where you cannot see
> the separation by CamelCase. Also a dash could be used instead of a
> decimal point.

 > Stick with the dot. Since Win95 there is no trouble using it inside the
> name. Comma works too, just decide (AFAIK the period is the most used
> around).

This was the topic many months ago when we first made the move the Github.
I prefer legibility instead of saving 1 or 2 characters. Yes, we use the
dot. Thanks for pointing it out, I will add the information.

> Where is the problem? All the new footprints are sexp based and you can
> regenerate them from the collection boead without issues.

> You and i, but there many people who are stuck to older kicad versions
> for a while.

And so they are stuck with non-github libraries, too.

> 7. Naming should be done from the general to the special.
> Se my remarks at general about going from general to special....

Yes exactly.

> here i would suggest to avoid the first dash, and only use the dash to
separate more
> details of the housing like "SOT23-3" or "SOT23-5"

We had decided to follow JEDEC Publication Number 95, Section 1.6 "Outline
Classification" which contains the dash, for more legibility.

> If i create a array with and without detached representation, like
> a resistor array, how should this be named?

Symbol names haven't been specified yet in the convention. I'll think about
it very soon.

> If it is a generic footprint, the manufacturer should be omitted. But if
> it is a very special footprint, only for one manufacturer, it should be
> NOT omitted. If there is a manufacturer known for his specific housings,
> there should be a library for especially this manufacturer, an for this
> special case, the name should start with the manufacturer.

> Keep in mind, that it will be costly in any case to search for an
> offical name, if you have only a manufacturer spezific name.

Yeah, I do think we will have to allow for manufacturer-specific libraries.

>This is dangerous, because it seems always dangerous to use special
> characters (with the exeption of -. and _ at file or folder names, even
> if they are allowed in the filesystem itsself and the actual program.
> So i would suggest to add an CamelCase "And". If there is a problem to
> separate from leading capital letters, so use a dash "-" .

What we will do instead is consider the extra pad as a variation of the
package. So we'll use a dash, as per rule 4.

> Of course, but where will you append the reason exact. Not in the name,
> i think, i think more in a commit?

Yes, in package name.

> At some librarys, the intended meaning of Value and reference seems to
> be mixed up. Perhaps it would be usefull to write it explicite down:

Good idea.

> I thougt about: For a small schematic i prefare to have the 555 black
> box with all pin positions at the right position. So it will be fast to
> recognize the pins at the real IC for error hunting.

I do that, too, but at the same time I feel it tends to make messier
schematics.

> Sorry, but creating multiple footprints is creating a mess. Creating
multiple symbols is an element that attracts (future) users. > Many of them
evaluates the quality of the EDA software by the number of elements in the
libraries, especially symbols.

I lean towards this.

On Fri, May 16, 2014 at 1:54 PM, Lorenzo Marcantonio <
l.marcantonio@xxxxxxxxxxxx> wrote:

> On Fri, May 16, 2014 at 06:08:27PM +0200, Kerusey Karyu wrote:
> > > it's just easier to duplicate the package and
> > > rename the pins :D
> > >
> > It's easiest to create proper symbols. :P
>
> I guess is a workflow preference thing:P I prefer to duplicate modules
> to get good pin names, you prefer to duplicate schematic symbols to keep
> the same pin numbers.
>
> Aliases wouldn't help since the pinning on the symbol is different,
> anyway.
>
> At the end is personal preference IMHO. I don't know if it's
> easier/faster to duplicate and change a symbol or duplicate and change
> a module, but it would be more or less the same...
>
> Another holy war averted :D
>
> --
> Lorenzo Marcantonio
> Logos Srl
>
> --
> Mailing list: https://launchpad.net/~kicad-lib-committers
> Post to     : kicad-lib-committers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-lib-committers
> More help   : https://help.launchpad.net/ListHelp
>