← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #35868

Re: More default fields in schematic

  Thread Previous • Date Previous • • Thread Next
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 designs incompatable, resulting in 100 different fields, but only describing 10 different things
Is this feature not > useful enough or not documented well enough for users? Hard coding >
default field names that no one can agree upon is not going to > happen. The problem is that they will spell differently, MPN, MFPN, #mfg, ManufPart, etc etc The problem is really that those who want to embedd the part number can not to that in an easy way, they cannot set the field in any compatible way, creating many problems for people that has to compare/view others design. Many hours can be lost, just because the simple phrase "Set the Manufacturers Part number in the schematic of your desing", all that can be solved by a single step of spelling the value name for the users. Ofcourse they will still be able to change it later if they want.
the same optional field names for every project without having to add > them by hand to each symbol As long as you assume there will only
ever be one person involved here, and that they will always use the same computer over the projects lifetime. > 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. I would like this as well, all I want is a default name, to give users a hint, I really do not care where it is set, or even if there would be a lot of fields that I personally will never use in it, because it is much easier to remove the fields than to add them in a uniform way over the globe. Still though, I think having the fields set in eeschema is better, makes my changes stick over different projects. > 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 free from the fields, sure. Otherwise we are back at square one, and we added a lot of shit, helping no one. - Kristoffer On 2018-05-22 00:22, Wayne Stambaugh wrote:
introduced a change that allows the user to define a custom template > path which takes precedence over the system template path so this >
solution is workable. 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. > > 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 >> <kristofferodmark90@xxxxxxxxx >> <mailto:kristofferodmark90@xxxxxxxxx>> 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 >> <kristofferodmark90@xxxxxxxxx >> <mailto:kristofferodmark90@xxxxxxxxx> >> <mailto:kristofferodmark90@xxxxxxxxx >> <mailto:kristofferodmark90@xxxxxxxxx>>> wrote: >> >> The patch should only affect first startup, changes to the fields >> will be saved >> >> On May 20, 2018 22:18, "Seth Hillbrand" <seth.hillbrand@xxxxxxxxx >> <mailto:seth.hillbrand@xxxxxxxxx> <mailto:seth.hillbrand@xxxxxxxxx >> <mailto:seth.hillbrand@xxxxxxxxx>>> 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 >> <kristofferodmark90@xxxxxxxxx >> <mailto:kristofferodmark90@xxxxxxxxx> >> <mailto:kristofferodmark90@xxxxxxxxx >> <mailto:kristofferodmark90@xxxxxxxxx>>>: >> >> >> 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/master/MCP3002-I_SN.lib >> >> <https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib>
>>
<https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib >> >> <https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib>>
>>
https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch >> >> <https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch>
>>
<https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch >> >> <https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch>>
>>
https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib >> >> <https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib>
>>
<https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib >> >> <https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib>>
>> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib >>
<https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib> >> >> <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib >> <https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.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@xxxxxxxxxxxxxxxxxxx >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>> 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> >> <https://launchpad.net/%7Ekicad-developers >> <https://launchpad.net/%7Ekicad-developers>> Post to : >> kicad-developers@xxxxxxxxxxxxxxxxxxx >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx> 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] >> >> kandrey89@xxxxxxxxx <mailto:kandrey89@xxxxxxxxx> Live Long and >> Prosper, Andrey >> >> >> _______________________________________________ Mailing list: >> https://launchpad.net/~kicad-developers Post to : >> kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : >> https://launchpad.net/~kicad-developers More help : >> https://help.launchpad.net/ListHelp >> > > _______________________________________________ Mailing list: > https://launchpad.net/~kicad-developers Post to : > kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : > https://launchpad.net/~kicad-developers More help : > https://help.launchpad.net/ListHelp 


>From 8a81d27424e96bd4abeec7d1fdaa68774d6522b3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= <kristoffer.odmark90@xxxxxxxxx>
Date: Sun, 20 May 2018 21:59:13 +0200
Subject: [PATCH] Added default fields, not affect previous designs

There is a problem of coherency for people using Manufacturer
Part Number in the schematic. This solves that.

Added default fields for Tolerance, Manufacturer, MPN
the default values are empty, so they will not be stored
in schematic symbols or designs unless they are set to
something.

This will mean that people who does not use them, will not
be bothered, and people who wants to use them, will have a
easier time.
---
 eeschema/eeschema_config.cpp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/eeschema/eeschema_config.cpp b/eeschema/eeschema_config.cpp
index 205ab2674..53b510bac 100644
--- a/eeschema/eeschema_config.cpp
+++ b/eeschema/eeschema_config.cpp
@@ -588,7 +588,10 @@ void SCH_EDIT_FRAME::LoadSettings( wxConfigBase* aCfg )
             m_replaceStringHistoryList.Add( tmpHistory );
     }
 
-    wxString templateFieldNames = aCfg->Read( FieldNamesEntry, wxEmptyString );
+    // Read the template field settings, use default if no found
+    const wxString defaultTemplateFieldNames =
+            "(templatefields (field (name Tolerance)(value ~)) (field (name Manufacturer)(value ~)) (field (name MPN)(value ~)))";
+    wxString templateFieldNames = aCfg->Read( FieldNamesEntry, defaultTemplateFieldNames );
 
     if( !templateFieldNames.IsEmpty() )
     {
-- 
2.17.0

References

  Thread Previous • Date Previous • • Thread Next