I think I like this new patch. It provides the /opportunity/ for uniformity, without getting in the way of those who want to go their own way.
Do the BOM generators automatically output all default fields or only those with values? > On 22 May 2018, at 09:22, kristoffer ödmark <kristofferodmar...@gmail.com> > wrote: > > Please disregard my previous mail, it got mangled badly somehow, it did > not look like that in my editor at least. > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote: >> Eeschema already supports creating default optional fields in the >> configuration settings dialog. Used correctly, these will give you >> the >> same optional field names for every project without having to add >> them >> by hand to each symbol and possibly typing in different field names >> by >> accident. > > Different users will still type in different field names for the same > things though. What you describe works as long as there is only one > person in the entire projects lifetime, using only one computer. > >> The proposed patch would intermingle the default fields >> with >> existing schematic symbol fields which would break existing BOMs >> which I >> don't think users will appreciate. > > The proposed patch will only change default settings, existing users > with a config already in place will not be affected. I realised that > the fields now accept empty values as well, so existing boms on new > installations will not be affected either. I updated the patch, so it > will not affect anyone that doesnt use the fields. > >> [...] As I've stated before, I can set 10 >> different designers down and I will get 10 different sets of default >> field names. This really seems like me to be a configuration issue. > > This is the problems I want to address, because those 10 designers will > by experience also spell the same field in 10 different ways. Making > their fields incompatable. MPN, MFPN, #mfg, ManufPart, etc etc. Let > those 10 designers remove the fields they do not want instead. > >> The only possible solution that I would accept is to move the default >> field definitions from the eeschema configuration file into the >> default >> kicad project file. This way existing projects would not be polluted >> with the proposed default fields and users could define their own >> default fields in a custom project file. > > Default fields does not pollute if they are empty, they just give a > hint of what data could be put into the schematic, same as with the > datasheet field, which is not often used. Funny how noone ever > complains about that one. > >> [...] >> A more flexible solution would be to add a "File->New from Custom >> Template" command to KiCad to allow the user to select any custom >> project file. This would allow for multiple custom project files >> instead of forcing the user to use only a single default project >> file. > > As long as the "File->New Project" would include the additional fields > and then people can use "New from Custom Template" means they can use a > template that is empty. Otherwise it would defeat the purpose. I am > proposing a slightly different default configuration, not any change in > how people will use the software. > >> >> Cheers, >> >> Wayne >> >> On 05/20/2018 06:27 PM, Andrey Kuznetsov wrote: >>> I agree, I had the same issue when I was doing my board, I needed a >>> field for all components, and I had to manually add it for every >>> item, >>> there was no way to add this field to all components at the same >>> time or >>> to have it add by default from the addition of a new component to >>> the sheet. >>> >>> Which reminds me, Cadence Designer has tools to manipulate fields >>> on a >>> large scale, whether to add, delete, show, hide, etc, this is >>> something >>> that would be nice to have in KiCAD, either that or a table of all >>> components for the sheet or schematic and columns for each field, >>> with >>> ability to show/hide each cell individually. >>> >>> I think the ultimate goal is to make the Symbol Table more useful, >>> but >>> that'll take to long for v5 so if Kristoffer's patch allows an easy >>> way >>> to add fields to all components or similar, I'd say do it because >>> people >>> will be pissed and waste their time doing it for every component in >>> their schematic. >>> >>> On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark >>> <kristofferodmar...@gmail.com <mailto:kristofferodmar...@gmail.com> >>>> wrote: >>> >>> I obvviously disagree, the correct solution would be to have >>> both. >>> This does not hinder that, its not even the same problem. >>> >>> The problem is for everyone who want for example the >>> Manufacturer >>> Part Number will have to define a fieldname, which every time >>> results in them abbreviating it to something different. Hence >>> nobody >>> can work with Manufacturer Part Numbers. >>> >>> Here is something similar, Imagine all of the colours in Kicad >>> for >>> all of the layers where white by default. Have fun defining all >>> the >>> colours yourself. >>> Maybe you want to define them yourself, nobody is stopping you >>> now >>> either, just get cracking. >>> >>> How easy would it be for you to look at the board someone else >>> made >>> later and understand what is what? Maybe for some that is a >>> better >>> solution, but for me that >>> would be an extreme example of bad default values. >>> >>> This is how the default fields are now, they are white, or more >>> like >>> see-throught, which makes life harder for anyone that >>> wants to contribute or create tools that interact with kicad, >>> and as >>> I previously said, this is only a default, you are still >>> equally able to add/remove or change the fields how you want >>> to. >>> But, tools like kibom or various other web-based tools can much >>> easier integrate to it, or at least support a default value as >>> well. >>> So for the majority of users, who doesnt change defaults, >>> the tool would just work. >>> >>> I will reiterate, I do not care what they are named, I want a >>> default field where I can put my manufacturer part number, >>> amongs >>> others. >>> The specific abbreviation or name does not matter, If i care, I >>> can >>> manually add/remove my own fields *JUST AS I DO NOW*, but for >>> the people >>> who use it, it will be easier across projects, for the people >>> that >>> dont, It will not matter. >>> >>> Sane defaults matter. A lot actually. >>> >>> - Kristoffer >>> >>> On 2018-05-20 23:40, José Ignacio wrote: >>> >>> I dont like this, the right solution would be to allow for >>> importing a default config into kicad for things like that, >>> as >>> different groups will have different policies. >>> >>> On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark >>> <kristofferodmar...@gmail.com >>> <mailto:kristofferodmar...@gmail.com> >>> <mailto:kristofferodmar...@gmail.com >>> <mailto:kristofferodmar...@gmail.com>>> wrote: >>> >>> The patch should only affect first startup, changes to >>> the >>> fields >>> will be saved >>> >>> On May 20, 2018 22:18, "Seth Hillbrand" >>> <seth.hillbr...@gmail.com <mailto:seth.hillbr...@gmail.com> >>> <mailto:seth.hillbr...@gmail.com >>> <mailto:seth.hillbr...@gmail.com>>> wrote: >>> >>> Hi Kristoffer- >>> >>> This feels like a management issue rather than a >>> tool >>> issue. >>> If the user doesn't want any extra fields, how >>> would your >>> patch allow that? >>> >>> -S >>> >>> >>> Am So., 20. Mai 2018 um 13:00 Uhr schrieb >>> kristoffer Ödmark >>> <kristofferodmar...@gmail.com >>> <mailto:kristofferodmar...@gmail.com> >>> <mailto:kristofferodmar...@gmail.com >>> <mailto:kristofferodmar...@gmail.com>>>: >>> >>> >>> Hello! >>> >>> I will open this can of worms again, I feel >>> that I have >>> to. So from what >>> I gather we have proffessionals as the main aim >>> in >>> Kicad. >>> The reason I will open this issue again is that >>> I >>> feel we >>> have a >>> collaboration issue, maybe not a mayor one. But >>> one >>> nonetheless. >>> >>> We really need more default fields for our >>> schematic >>> symbols. Im not >>> proposing required fields, I am *ONLY* >>> proposing that >>> there should be default fields added into the >>> default >>> fields settings >>> tab. I am not proposing they need to be filled >>> in the >>> libraries, nor that people need to use them. >>> only that >>> they need to >>> exist with a fresh install of kicad so that >>> easy >>> problems >>> such as theese do not happen: >>> >>> - Collaborators working on the same >>> project >>> will not >>> create >>> duplicate fields in libs/projects describing >>> the same >>> thing by mistake >>> - Projects that aim to interact or add to >>> Kicad can >>> assume that the >>> Fields will exist, and will know what name/tag >>> to >>> look for >>> (bom exporters, price checkers, >>> MacroFab, etc) >>> - Open source projects will be easier to >>> collaborate, >>> read and order >>> >>> The reason I think it is better to have the >>> fields by >>> default than the >>> current solution to add them is that the >>> majority >>> will use >>> what exists, and tools can support it from the >>> very >>> beginning, people >>> with inhouse tools seems to dislike this, since >>> they >>> map their >>> parts with an inhouse number - and then handle >>> the >>> information about the >>> part there. From what I gather, this is not the >>> majority, and >>> these persons still modify the default fields >>> settings. >>> >>> I spent maybe 30-40 mins checking the "made >>> with kicad" >>> projects, I >>> found that the most common addition to libs and >>> schematics >>> are: >>> - Manufacturers part number, these were >>> named >>> widely >>> different in >>> projects, (BOM, MP, MPN, #mfg, or different >>> syntaxes in >>> the Value field ) >>> I even saw a mix of these in the same >>> project >>> once, along with >>> some people having the vendor id only. >>> - Manufacturer ( found some different >>> languages >>> though ) >>> >>> more uncommon things was, Tolerance( 10%, >>> 20pps), >>> Ratings >>> ( 1/4W, 85C, >>> 16V ), Vendor information and different >>> Descriptions. They >>> were named >>> and abbreviated >>> very differently accross projects. >>> >>> What I would like to see is these additional >>> fields by >>> default, but >>> hidden from the schematic unless changed by >>> user. >>> Tolerance ( used for setting tolerances of >>> resistors, >>> capacitors, >>> oscillators, etc ) >>> MaxRating ( field were one can specify max >>> Voltage, >>> Ampere, >>> Frequency, or whatever the component needs ) >>> Manufacturer ( For inhouse numbers, they >>> could >>> either >>> just remove >>> it, or use the company/group name ) >>> MPN ( Maybe PartNumber could be used here, >>> and >>> people >>> who use >>> inhouse numbers use it aswell, I dont really >>> care >>> what its >>> called, as >>> long as its called something ) >>> Vendor >>> Notes >>> >>> I would be all up for extra additions/removals, >>> but I >>> would prefer if >>> the naming is not discussed, but rather just >>> decided/agreed upon by >>> someone in the lead team. >>> The very least I think should be added in case >>> the >>> previous is to much are: >>> Tolerance >>> Manufacturer >>> MPN >>> >>> I attach a patch for the minimal set, tested on >>> linux by >>> removing the >>> .config/kicad/eeschema file. >>> >>> - Kristoffer >>> >>> >>> ps >>> Some github files i reviewed, not all: >>> >>> https://github.com/AnaviTechnology/anavi-gardening/blob/mas >>> ter/MCP3002-I_SN.lib >>> <https://github.com/AnaviTechnology/anavi-gardening/blob/ma >>> ster/MCP3002-I_SN.lib> >>> >>> <https://github.com/AnaviTechnology/anavi-gardening/blob/ma >>> ster/MCP3002-I_SN.lib >>> <https://github.com/AnaviTechnology/anavi-gardening/blob/ma >>> ster/MCP3002-I_SN.lib>> >>> >>> https://github.com/jonpe960/blixten/blob/master/Blixten%20L >>> ED%20Device/Blixten.sch >>> <https://github.com/jonpe960/blixten/blob/master/Blixten%20 >>> LED%20Device/Blixten.sch> >>> >>> <https://github.com/jonpe960/blixten/blob/master/Blixten%20 >>> LED%20Device/Blixten.sch >>> <https://github.com/jonpe960/blixten/blob/master/Blixten%20 >>> LED%20Device/Blixten.sch>> >>> >>> https://github.com/paltatech/half-bridge/blob/master/pcb%20 >>> design/IGBT_board-cache.lib >>> <https://github.com/paltatech/half-bridge/blob/master/pcb%2 >>> 0design/IGBT_board-cache.lib> >>> >>> <https://github.com/paltatech/half-bridge/blob/master/pcb%2 >>> 0design/IGBT_board-cache.lib >>> <https://github.com/paltatech/half-bridge/blob/master/pcb%2 >>> 0design/IGBT_board-cache.lib>> >>> >>> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_sm >>> d.lib >>> <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_s >>> md.lib> >>> >>> <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_s >>> md.lib <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_sm >>> d.lib>> >>> >>> https://github.com/jim17/memtype/blob/master/schematic_pcb/ >>> electronic_design_kicad/electronic_design_kicad.sch >>> <https://github.com/jim17/memtype/blob/master/schematic_pcb >>> /electronic_design_kicad/electronic_design_kicad.sch> >>> >>> <https://github.com/jim17/memtype/blob/master/schematic_pcb >>> /electronic_design_kicad/electronic_design_kicad.sch >>> <https://github.com/jim17/memtype/blob/master/schematic_pcb >>> /electronic_design_kicad/electronic_design_kicad.sch>> >>> _______________________________________________ >>> Mailing list: >>> https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> <https://launchpad.net/%7Ekicad-developers >>> <https://launchpad.net/%7Ekicad-developers>> >>> Post to : kicad-developers@lists.launchpad. >>> net >>> <mailto:kicad-developers@lists.launchpad.net> >>> <mailto:kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net>> >>> Unsubscribe : >>> https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> <https://launchpad.net/%7Ekicad-developers >>> <https://launchpad.net/%7Ekicad-developers>> >>> More help : https://help.launchpad.net/ListHe >>> lp >>> <https://help.launchpad.net/ListHelp> >>> <https://help.launchpad.net/ListHelp >>> <https://help.launchpad.net/ListHelp>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> <https://launchpad.net/%7Ekicad-developers >>> <https://launchpad.net/%7Ekicad-developers>> >>> Post to : kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> <mailto:kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net>> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> <https://launchpad.net/%7Ekicad-developers >>> <https://launchpad.net/%7Ekicad-developers>> >>> More help : https://help.launchpad.net/ListHelp >>> <https://help.launchpad.net/ListHelp> >>> <https://help.launchpad.net/ListHelp >>> <https://help.launchpad.net/ListHelp>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> Post to : kicad-developers@lists.launchpad.net >>> <mailto:kicad-developers@lists.launchpad.net> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> <https://launchpad.net/~kicad-developers> >>> More help : https://help.launchpad.net/ListHelp >>> <https://help.launchpad.net/ListHelp> >>> >>> >>> >>> >>> -- >>> Remember The Past, Live The Present, Change The Future >>> Those who look only to the past or the present are certain to miss >>> the >>> future [JFK] >>> >>> kandre...@gmail.com <mailto:kandre...@gmail.com> >>> Live Long and Prosper, >>> Andrey >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > <0001-Added-default-fields-not-affect-previous-designs.patch>_______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > Post to : kicad-developers@lists.launchpad.net > <mailto:kicad-developers@lists.launchpad.net> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad.net/ListHelp>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp