> 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 < [email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-lib-committers > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~kicad-lib-committers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-lib-committers More help : https://help.launchpad.net/ListHelp
