Assigning a new value to an IDProperty with the Python API would free
the entire contents of the existing property, which unfortunately
happened to include the UI data. The fix is to extract the UI data from
the existing property before freeing its contents. An alternative
would be adding another argument to `IDP_FreePropertyContent_ex`, but
this solution is clearer and doesn't increase complexity elsewhere.
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
- Matches changes in Python 3.x dictionary methods.
- Iterating now raises a run-time error if the property-group changes
size during iteration.
- IDPropertyGroup.iteritems() has been removed.
- IDPropertyGroup View & Iterator types have been added.
- Some set functionality from dict_keys/values/items aren't yet
supported (isdisjoint method and boolean set style operations).
Proposed as part of T85675.
The id-property iterator referenced a PyObject pointer without
increasing it's user count - allowing for errors if the value
goes out of scope during iteration.
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
This reverts commit cbae82ba96.
This change introduced the following problems:
- We could no longer reliably duplicate or use an existing
custom property names.
- We could no longer assume a bone or ID name
can be used in a custom-property.
- Importers that support custom properties (such as FBX)
could fail with an exception creating custom properties.
While `tp_print` was deprecated, Python 3.8+ uses this for
'tp_vectorcall_offset' which wasn't stated in the comment from
efd71aad4f.
Instead of suppressing clang-tidy, use preprocessor a check since
this properly represents the difference between Python versions.
Some characters: `'`, `"`, and `\`, can cause problems with RNA paths.
Instead of using more complicated handling to deal with those cases,
we can just prevent these characters from being used in custom property
names.
This commit checks for these characters to `idp_try_read_name`, where
other checks like length are already done.
Differential Revision: https://developer.blender.org/D8839
Do not see any reason not to copy over the flag of the old, existing
IDProp to the new one when assigning (e.g. `C.object['prop'] = 0.5`
would nuke that IDProp flag).
This also makes `IDP_CopyProperty` the "opposite"
of `IDP_FreeProperty`, which is what I'd expect.
Two refactoring steps:
* rename IDP_FreeProperty to IDP_FreePropertyContent
* new IDP_FreeProperty function that actually frees the property
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4872
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Using 'format' prefix made this read as if t was for string formatting.
Use 'PyC_StructFmt' prefix instead since these values are compatible
with formatting from Python's 'struct' module.
