Hi All,
If I may, a side note:
some time ago I was working on an external board optimization tool and
it required new parameters both to schematic and to board files. i know,
that it doesn't tell any good about my dedication, but the project is
now shelved once i discovered that both pcb and sch will either fail on
reading such file with unknown property or not preserve it across read /
write cycle.
So: shouldn't such behavior be taken as a bug and fixed? (from what I
can tell from sources, it's currently perceived as a required feature).
-R
On 3/18/26 03:42, RAY5D wrote:
Hi, Jon!
(My last message was stuck on sending... rewriting here, will delete
duplicates if I see any. )
Thanks for the clarification. So, basically, all built-in objects are
properties, except for the 5 you've mentioned that are fields, is that
correct? Also, by "Description for footprints", do you mean the
description for symbols are different? How about the description for
atomic parts in a database library? I tried to modify the database
config in some crazy ways, and found out that the description can
either be defined as a field or a property, which seems rather
strange. Here's what I tried. Let's take the example config in the
documentation as a template...
...
"libraries": [
{
"name": "Resistors",
"table": "Resistors",
"key": "Part ID",
"symbols": "Symbols", // I'm
gonna call this the dedicated section
"footprints": "Footprints",
"fields": [
{ // this is
definitely in fields
"column": "MPN",
"name": "MPN",
"visible_on_add": false,
"visible_in_chooser": true,
"show_name": true,
"inherit_properties": true
},
...
],
"properties": {
"description": "Description", // and
these are properties
"footprint_filters": "Footprint Filters",
...
}
}
]
and the entries work in these sections:
Dedicated Fields Properties
Reference Did not test, obviously don't want this to be set by the
database :)
Symbols Yes No No
Footprints Yes No No
Value No Yes No
Datasheet No Yes No
Description No Yes Yes
Everything seems pretty clear except for the description. Is it
expected to work in either places? What is the more
preferred/supported place to put it? Thanks!
RAY5D
On Tuesday, March 17, 2026 at 11:45:06 AM UTC-5 [email protected] wrote:
In general, "property" means something where KiCad code defines
its existence and it is a built-in piece of information about an
object.
"field" means a special type of child object that some objects
(e.g. sheets, symbols, footprints) can have. Fields are special
text objects that can have a name (key) and value.
The place where the lines are blurred here is that KiCad defines
"built-in" fields for symbols and footprints. These are
Reference, Value, Footprint, Datasheet, and Description for
footprints.
Why are these fields and not properties? Well, part of it is just
down to how the code has evolved over a long time, and part of it
is because it is fairly standard to want to have the reference
(and often value) show up as fields (text objects that appear on
the physical board) rather than just properties (data inside the
board). Should the footprint and datasheet be properties rather
than fields? Probably yes, but that ship sailed long ago.
The database library configuration file pulls out all
"first-class" information into top level keys for a library
configuration, and uses the "fields" array in the config file for
*user-defined fields*. So for example even though there is a
Footprint field on a symbol, you don't put the footprint
configuration in the "fields" section. So, to answer your
original question, if you want to add custom data to your
symbols/footprints from the database, add them to the fields array
in the kicad_dbl file.
-Jon
On Tue, Mar 17, 2026 at 12:12 PM RAY5D <[email protected]> wrote:
Hello, Kicad Devs
I'm trying to setup a database library to manage my parts, but
got a bit confused with whether to specify component
parameters in "fields" or "properties" in the database config
file. I found this forum post
<https://forum.kicad.info/t/what-is-a-property-what-is-a-field/62078>
which
showed a rather mixed example and no replies, and this repo
issue
<https://gitlab.com/kicad/code/kicad/-/work_items/10404> which
seemed to suggest they are synonymous. The Kicad documentation
has no mention on how they are different either. Can someone
explain if it's really only internal to the code base and
doesn't matter in a user's view, or they are different and I
should stick to a standard written down somewhere? And maybe
the dev team's intention on how to handle the two types of
parameters in future updates? Thanks!
RAY5D
--
You received this message because you are subscribed to the
Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/ab6cc904-21d9-409d-a1f2-84f9a1000e95n%40kicad.org
<https://groups.google.com/a/kicad.org/d/msgid/devlist/ab6cc904-21d9-409d-a1f2-84f9a1000e95n%40kicad.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/a0865398-4965-46c5-a31f-2e001a0616bfn%40kicad.org
<https://groups.google.com/a/kicad.org/d/msgid/devlist/a0865398-4965-46c5-a31f-2e001a0616bfn%40kicad.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "KiCad
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/f75cfd2d-9199-42e9-a814-2a8960b99ef0%40electric-sheep.eu.
