kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 21/12/2016 à 17:19, Kaspar Emanuel a écrit :
> Thank you Clemens and Kevin for your responses.
> 
> Clemens, you raise that you are not happy with hard-coding fields at all because there is no
> standard way to do it. But KiCad’s symbols already come with a datasheet field for instance. To me,
> the datasheet field is way less useful than an MPN field. In any case we are trying to come up with
> a better, standard way to do it, what's the problem with that?
> 
> You then go on to describe your method and say you have no use case for it. That’s fair enough but I
> think its clean that I and a few other people /do/ have a use case. Furthermore, the proposal, if
> implemented, shouldn’t affect your way of working at all.
> 
> Kevin, you say that this would not work for generic components like resistors and capacitors. I
> don’t think I was clear enough: the proposal is to add a standard MPN field to schematic symbols to
> be populated /when they are part of a schematic/, i.e. their values (and tolerances etc) have been
> assigned. Really we are talking about the schematic format.

Kaspar,

Adding a new field does not imply a schematic format change.
You can already add any field to a schematic component or a library component (library part)

I don't really understand why you are thinking the schematic file format should be modified.

If you want to see a user field always existing in your component editor, just add this field name
and a default value in the schematic editor options (Default fields).

The feature you want is already available since many years in Eeschema.

The spice simulator also uses predefined fields to store simulator parameters in lib or in schematic.
AFAIK, it works without issues, and without any change in schematic file format.

For me, the main question is:
>From the point of view of the *schematic editor*, what is the purpose of this field?
(I am not talking about the user point of view)

> 
> Your alternative system is interesting but/is/ a bit more complicated. Standardizing on an MPN field
> is something existing tooling could make use of very quickly but with yours they would have to
> change their way of working quite substantively. I think further discussion of your proposal is a
> separate point and should continue in another thread.
> 
> All the best,
> 
> Kaspar
> 

-- 
Jean-Pierre CHARRAS