2023-05-31 16:19:06 +02:00
|
|
|
/* SPDX-FileCopyrightText: 2001-2002 NaN Holding BV. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2011-02-27 20:40:57 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
2011-02-27 20:40:57 +00:00
|
|
|
*/
|
|
|
|
|
|
2023-08-19 23:44:21 +10:00
|
|
|
#include <cfloat>
|
2023-07-22 11:27:25 +10:00
|
|
|
#include <climits>
|
|
|
|
|
#include <cstddef>
|
|
|
|
|
#include <cstdio>
|
|
|
|
|
#include <cstdlib>
|
|
|
|
|
#include <cstring>
|
2007-12-24 18:38:03 +00:00
|
|
|
|
2023-12-15 10:20:44 +01:00
|
|
|
#include <fmt/format.h>
|
|
|
|
|
|
2020-08-21 12:45:33 +02:00
|
|
|
#include "BLI_endian_switch.h"
|
2012-07-08 06:00:27 +00:00
|
|
|
#include "BLI_listbase.h"
|
Cleanup: reduce amount of math-related includes
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
2023-08-09 11:39:20 +03:00
|
|
|
#include "BLI_math_base.h"
|
2023-12-15 10:20:44 +01:00
|
|
|
#include "BLI_set.hh"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_string.h"
|
|
|
|
|
#include "BLI_utildefines.h"
|
2012-07-08 06:00:27 +00:00
|
|
|
|
2024-03-26 12:57:30 -04:00
|
|
|
#include "BKE_idprop.hh"
|
2024-01-15 12:44:04 -05:00
|
|
|
#include "BKE_lib_id.hh"
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2019-02-01 12:44:19 +11:00
|
|
|
#include "CLG_log.h"
|
|
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2023-08-28 15:01:05 +02:00
|
|
|
#include "BLO_read_write.hh"
|
2020-08-21 12:45:33 +02:00
|
|
|
|
2025-01-26 20:07:57 +01:00
|
|
|
#include "BLI_strict_flags.h" /* IWYU pragma: keep. Keep last. */
|
2014-12-12 16:17:52 +01:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
/* IDPropertyTemplate is a union in DNA_ID.h */
|
2007-04-19 22:49:48 +00:00
|
|
|
|
2014-12-12 16:17:52 +01:00
|
|
|
/**
|
|
|
|
|
* if the new is 'IDP_ARRAY_REALLOC_LIMIT' items less,
|
|
|
|
|
* than #IDProperty.totallen, reallocate anyway.
|
|
|
|
|
*/
|
|
|
|
|
#define IDP_ARRAY_REALLOC_LIMIT 200
|
|
|
|
|
|
2019-02-01 12:44:19 +11:00
|
|
|
static CLG_LogRef LOG = {"bke.idprop"};
|
|
|
|
|
|
2023-01-17 11:51:07 +11:00
|
|
|
/** Local size table, aligned with #eIDPropertyType. */
|
2014-12-12 16:17:52 +01:00
|
|
|
static size_t idp_size_table[] = {
|
2023-01-17 11:51:07 +11:00
|
|
|
1, /* #IDP_STRING */
|
|
|
|
|
sizeof(int), /* #IDP_INT */
|
|
|
|
|
sizeof(float), /* #IDP_FLOAT */
|
|
|
|
|
sizeof(float[3]), /* DEPRECATED (was vector). */
|
|
|
|
|
sizeof(float[16]), /* DEPRECATED (was matrix). */
|
|
|
|
|
0, /* #IDP_ARRAY (no fixed size). */
|
|
|
|
|
sizeof(ListBase), /* #IDP_GROUP */
|
|
|
|
|
sizeof(void *), /* #IDP_ID */
|
|
|
|
|
sizeof(double), /* #IDP_DOUBLE */
|
|
|
|
|
0, /* #IDP_IDPARRAY (no fixed size). */
|
|
|
|
|
sizeof(int8_t), /* #IDP_BOOLEAN */
|
2024-01-26 12:40:01 +01:00
|
|
|
sizeof(int), /* #IDP_ENUM */
|
2006-11-17 04:46:48 +00:00
|
|
|
};
|
|
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Array Functions (IDP Array API)
|
|
|
|
|
* \{ */
|
|
|
|
|
|
2014-08-01 21:59:42 +10:00
|
|
|
#define GETPROP(prop, i) &(IDP_IDPArray(prop)[i])
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2024-10-10 03:17:15 +02:00
|
|
|
IDProperty *IDP_NewIDPArray(const blender::StringRef name)
|
2008-12-31 13:16:37 +00:00
|
|
|
{
|
2025-03-20 11:25:19 +01:00
|
|
|
IDProperty *prop = MEM_callocN<IDProperty>("IDProperty prop array");
|
2008-12-31 13:16:37 +00:00
|
|
|
prop->type = IDP_IDPARRAY;
|
|
|
|
|
prop->len = 0;
|
2025-01-29 12:12:27 +01:00
|
|
|
name.copy_utf8_truncated(prop->name);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2008-12-31 13:16:37 +00:00
|
|
|
return prop;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
IDProperty *IDP_CopyIDPArray(const IDProperty *array, const int flag)
|
2008-12-31 13:16:37 +00:00
|
|
|
{
|
2012-03-18 07:38:51 +00:00
|
|
|
/* don't use MEM_dupallocN because this may be part of an array */
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(array->type == IDP_IDPARRAY);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-03-20 11:25:19 +01:00
|
|
|
IDProperty *narray = MEM_mallocN<IDProperty>(__func__);
|
2012-05-06 17:22:54 +00:00
|
|
|
*narray = *array;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2008-12-31 13:16:37 +00:00
|
|
|
narray->data.pointer = MEM_dupallocN(array->data.pointer);
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = 0; i < narray->len; i++) {
|
2021-06-26 21:35:18 +10:00
|
|
|
/* OK, the copy functions always allocate a new structure,
|
2012-03-03 20:19:11 +00:00
|
|
|
* which doesn't work here. instead, simply copy the
|
|
|
|
|
* contents of the new structure into the array cell,
|
|
|
|
|
* then free it. this makes for more maintainable
|
2020-02-13 14:01:52 +11:00
|
|
|
* code than simply re-implementing the copy functions
|
2021-06-26 21:35:18 +10:00
|
|
|
* in this loop. */
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *tmp = IDP_CopyProperty_ex(GETPROP(narray, i), flag);
|
2008-12-31 13:16:37 +00:00
|
|
|
memcpy(GETPROP(narray, i), tmp, sizeof(IDProperty));
|
|
|
|
|
MEM_freeN(tmp);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2008-12-31 13:16:37 +00:00
|
|
|
return narray;
|
|
|
|
|
}
|
|
|
|
|
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
static void IDP_FreeIDPArray(IDProperty *prop, const bool do_id_user)
|
2008-12-31 13:16:37 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_IDPARRAY);
|
|
|
|
|
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = 0; i < prop->len; i++) {
|
2019-05-16 14:17:11 +02:00
|
|
|
IDP_FreePropertyContent_ex(GETPROP(prop, i), do_id_user);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (prop->data.pointer) {
|
2008-12-31 13:16:37 +00:00
|
|
|
MEM_freeN(prop->data.pointer);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void IDP_SetIndexArray(IDProperty *prop, int index, IDProperty *item)
|
|
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_IDPARRAY);
|
|
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (index >= prop->len || index < 0) {
|
2017-03-30 22:52:12 +02:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2017-03-30 22:52:12 +02:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *old = GETPROP(prop, index);
|
2017-03-30 22:52:12 +02:00
|
|
|
if (item != old) {
|
2019-05-16 14:11:11 +02:00
|
|
|
IDP_FreePropertyContent(old);
|
2017-03-30 22:52:12 +02:00
|
|
|
|
|
|
|
|
memcpy(old, item, sizeof(IDProperty));
|
|
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
IDProperty *IDP_GetIndexArray(IDProperty *prop, int index)
|
|
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_IDPARRAY);
|
|
|
|
|
|
2008-12-31 13:16:37 +00:00
|
|
|
return GETPROP(prop, index);
|
|
|
|
|
}
|
|
|
|
|
|
2012-07-08 06:00:27 +00:00
|
|
|
void IDP_AppendArray(IDProperty *prop, IDProperty *item)
|
2008-12-31 13:16:37 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_IDPARRAY);
|
|
|
|
|
|
2012-05-06 17:22:54 +00:00
|
|
|
IDP_ResizeIDPArray(prop, prop->len + 1);
|
|
|
|
|
IDP_SetIndexArray(prop, prop->len - 1, item);
|
2008-12-31 13:16:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void IDP_ResizeIDPArray(IDProperty *prop, int newlen)
|
|
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_IDPARRAY);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-09-05 04:26:08 +00:00
|
|
|
/* first check if the array buffer size has room */
|
2013-05-15 14:36:58 +00:00
|
|
|
if (newlen <= prop->totallen) {
|
2014-12-12 16:17:52 +01:00
|
|
|
if (newlen < prop->len && prop->totallen - newlen < IDP_ARRAY_REALLOC_LIMIT) {
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = newlen; i < prop->len; i++) {
|
2019-05-16 14:11:11 +02:00
|
|
|
IDP_FreePropertyContent(GETPROP(prop, i));
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-05-15 14:36:58 +00:00
|
|
|
prop->len = newlen;
|
|
|
|
|
return;
|
|
|
|
|
}
|
2020-08-07 12:30:43 +02:00
|
|
|
if (newlen >= prop->len) {
|
2013-05-15 14:36:58 +00:00
|
|
|
prop->len = newlen;
|
|
|
|
|
return;
|
|
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-09-05 04:26:08 +00:00
|
|
|
/* free trailing items */
|
|
|
|
|
if (newlen < prop->len) {
|
|
|
|
|
/* newlen is smaller */
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = newlen; i < prop->len; i++) {
|
2019-05-16 14:11:11 +02:00
|
|
|
IDP_FreePropertyContent(GETPROP(prop, i));
|
2013-09-05 04:26:08 +00:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: This code comes from python, here's the corresponding comment. */
|
2008-12-31 13:16:37 +00:00
|
|
|
/* This over-allocates proportional to the list size, making room
|
2022-06-07 14:53:20 +10:00
|
|
|
* for additional growth. The over-allocation is mild, but is
|
2008-12-31 13:16:37 +00:00
|
|
|
* enough to give linear-time amortized behavior over a long
|
|
|
|
|
* sequence of appends() in the presence of a poorly-performing
|
|
|
|
|
* system realloc().
|
|
|
|
|
* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
|
|
|
|
|
*/
|
2021-01-25 23:47:56 -06:00
|
|
|
int newsize = newlen;
|
2008-12-31 13:16:37 +00:00
|
|
|
newsize = (newsize >> 3) + (newsize < 9 ? 3 : 6) + newsize;
|
2023-07-18 14:18:07 +10:00
|
|
|
prop->data.pointer = MEM_recallocN(prop->data.pointer, sizeof(IDProperty) * size_t(newsize));
|
2008-12-31 13:16:37 +00:00
|
|
|
prop->len = newlen;
|
|
|
|
|
prop->totallen = newsize;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ----------- Numerical Array Type ----------- */
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
static void idp_resize_group_array(IDProperty *prop, int newlen, void *newarr)
|
|
|
|
|
{
|
2019-04-22 09:39:35 +10:00
|
|
|
if (prop->subtype != IDP_GROUP) {
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
return;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (newlen >= prop->len) {
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
/* bigger */
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty **array = static_cast<IDProperty **>(newarr);
|
2021-01-25 23:47:56 -06:00
|
|
|
for (int a = prop->len; a < newlen; a++) {
|
2024-03-26 15:39:34 -04:00
|
|
|
array[a] = blender::bke::idprop::create_group("IDP_ResizeArray group").release();
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* smaller */
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty **array = static_cast<IDProperty **>(prop->data.pointer);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
for (int a = newlen; a < prop->len; a++) {
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
IDP_FreeProperty(array[a]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
void IDP_ResizeArray(IDProperty *prop, int newlen)
|
|
|
|
|
{
|
2013-09-05 04:26:08 +00:00
|
|
|
const bool is_grow = newlen >= prop->len;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-09-05 04:26:08 +00:00
|
|
|
/* first check if the array buffer size has room */
|
2014-12-12 16:17:52 +01:00
|
|
|
if (newlen <= prop->totallen && prop->totallen - newlen < IDP_ARRAY_REALLOC_LIMIT) {
|
2009-01-23 20:36:47 +00:00
|
|
|
idp_resize_group_array(prop, newlen, prop->data.pointer);
|
2006-11-17 04:46:48 +00:00
|
|
|
prop->len = newlen;
|
|
|
|
|
return;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: This code comes from python, here's the corresponding comment. */
|
2006-11-17 04:46:48 +00:00
|
|
|
/* This over-allocates proportional to the list size, making room
|
|
|
|
|
* for additional growth. The over-allocation is mild, but is
|
|
|
|
|
* enough to give linear-time amortized behavior over a long
|
|
|
|
|
* sequence of appends() in the presence of a poorly-performing
|
|
|
|
|
* system realloc().
|
|
|
|
|
* The growth pattern is: 0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
|
|
|
|
|
*/
|
2021-01-25 23:47:56 -06:00
|
|
|
int newsize = newlen;
|
2014-08-15 19:59:31 +10:00
|
|
|
newsize = (newsize >> 3) + (newsize < 9 ? 3 : 6) + newsize;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (is_grow == false) {
|
2013-09-05 04:26:08 +00:00
|
|
|
idp_resize_group_array(prop, newlen, prop->data.pointer);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-12-12 16:17:52 +01:00
|
|
|
prop->data.pointer = MEM_recallocN(prop->data.pointer,
|
2023-07-18 14:18:07 +10:00
|
|
|
idp_size_table[int(prop->subtype)] * size_t(newsize));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (is_grow == true) {
|
2013-09-05 04:26:08 +00:00
|
|
|
idp_resize_group_array(prop, newlen, prop->data.pointer);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
prop->len = newlen;
|
|
|
|
|
prop->totallen = newsize;
|
|
|
|
|
}
|
|
|
|
|
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
void IDP_FreeArray(IDProperty *prop)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
if (prop->data.pointer) {
|
2023-07-17 10:46:26 +02:00
|
|
|
idp_resize_group_array(prop, 0, nullptr);
|
2006-11-17 04:46:48 +00:00
|
|
|
MEM_freeN(prop->data.pointer);
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
IDPropertyUIData *IDP_ui_data_copy(const IDProperty *prop)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
IDPropertyUIData *dst_ui_data = static_cast<IDPropertyUIData *>(MEM_dupallocN(prop->ui_data));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
|
|
|
|
/* Copy extra type specific data. */
|
|
|
|
|
switch (IDP_ui_data_type(prop)) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
const IDPropertyUIDataString *src = (const IDPropertyUIDataString *)prop->ui_data;
|
|
|
|
|
IDPropertyUIDataString *dst = (IDPropertyUIDataString *)dst_ui_data;
|
2023-07-17 10:46:26 +02:00
|
|
|
dst->default_value = static_cast<char *>(MEM_dupallocN(src->default_value));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
const IDPropertyUIDataInt *src = (const IDPropertyUIDataInt *)prop->ui_data;
|
|
|
|
|
IDPropertyUIDataInt *dst = (IDPropertyUIDataInt *)dst_ui_data;
|
2023-07-17 10:46:26 +02:00
|
|
|
dst->default_array = static_cast<int *>(MEM_dupallocN(src->default_array));
|
2023-12-15 10:20:44 +01:00
|
|
|
dst->enum_items = static_cast<IDPropertyUIDataEnumItem *>(MEM_dupallocN(src->enum_items));
|
|
|
|
|
for (const int64_t i : blender::IndexRange(src->enum_items_num)) {
|
|
|
|
|
const IDPropertyUIDataEnumItem &src_item = src->enum_items[i];
|
|
|
|
|
IDPropertyUIDataEnumItem &dst_item = dst->enum_items[i];
|
|
|
|
|
dst_item.identifier = BLI_strdup(src_item.identifier);
|
|
|
|
|
dst_item.name = BLI_strdup_null(src_item.name);
|
|
|
|
|
dst_item.description = BLI_strdup_null(src_item.description);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
const IDPropertyUIDataBool *src = (const IDPropertyUIDataBool *)prop->ui_data;
|
|
|
|
|
IDPropertyUIDataBool *dst = (IDPropertyUIDataBool *)dst_ui_data;
|
2023-07-17 10:46:26 +02:00
|
|
|
dst->default_array = static_cast<int8_t *>(MEM_dupallocN(src->default_array));
|
2023-01-13 12:31:27 -06:00
|
|
|
break;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
const IDPropertyUIDataFloat *src = (const IDPropertyUIDataFloat *)prop->ui_data;
|
|
|
|
|
IDPropertyUIDataFloat *dst = (IDPropertyUIDataFloat *)dst_ui_data;
|
2023-07-17 10:46:26 +02:00
|
|
|
dst->default_array = static_cast<double *>(MEM_dupallocN(src->default_array));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
dst_ui_data->description = static_cast<char *>(MEM_dupallocN(prop->ui_data->description));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
|
|
|
|
return dst_ui_data;
|
|
|
|
|
}
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
static IDProperty *idp_generic_copy(const IDProperty *prop, const int /*flag*/)
|
2012-05-06 17:22:54 +00:00
|
|
|
{
|
2025-03-20 11:25:19 +01:00
|
|
|
IDProperty *newp = MEM_callocN<IDProperty>(__func__);
|
2007-07-09 20:42:14 +00:00
|
|
|
|
2023-05-09 12:50:37 +10:00
|
|
|
STRNCPY(newp->name, prop->name);
|
2007-07-09 20:42:14 +00:00
|
|
|
newp->type = prop->type;
|
|
|
|
|
newp->flag = prop->flag;
|
|
|
|
|
newp->data.val = prop->data.val;
|
2008-10-05 01:15:58 +00:00
|
|
|
newp->data.val2 = prop->data.val2;
|
2007-07-09 20:42:14 +00:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop->ui_data != nullptr) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
newp->ui_data = IDP_ui_data_copy(prop);
|
|
|
|
|
}
|
|
|
|
|
|
2007-07-09 20:42:14 +00:00
|
|
|
return newp;
|
2012-05-06 17:22:54 +00:00
|
|
|
}
|
2007-07-09 20:42:14 +00:00
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
static IDProperty *IDP_CopyArray(const IDProperty *prop, const int flag)
|
2007-07-09 20:42:14 +00:00
|
|
|
{
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
IDProperty *newp = idp_generic_copy(prop, flag);
|
2007-07-09 20:42:14 +00:00
|
|
|
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
if (prop->data.pointer) {
|
|
|
|
|
newp->data.pointer = MEM_dupallocN(prop->data.pointer);
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (prop->type == IDP_GROUP) {
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty **array = static_cast<IDProperty **>(newp->data.pointer);
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
int a;
|
|
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
for (a = 0; a < prop->len; a++) {
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
array[a] = IDP_CopyProperty_ex(array[a], flag);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
RNA:
* Added support for using pointers + collections as operator properties,
but with the restriction that they must point to other type derived from
ID property groups. The "add" function for these properties will allocate
a new ID property group and point to that.
* Added support for arrays with type IDP_GROUP in ID properties.
* Fix bug getting/setting float array values.
Example code for collections, note the "OperatorMousePath" type is defined
in rna_wm.c and has a float[2] property named "loc".
Defining the operator property:
prop= RNA_def_property(ot->srna, "path", PROP_COLLECTION, PROP_NONE);
RNA_def_property_struct_runtime(prop, &RNA_OperatorMousePath);
Adding values:
PointerRNA itemptr;
float loc[2] = {1, 1},
RNA_collection_add(op->ptr, "path", &itemptr);
RNA_float_set_array(&itemptr, "loc", loc);
Iterating:
RNA_BEGIN(op->ptr, itemptr, "path") {
float loc[2];
RNA_float_get_array(&itemptr, "loc", loc);
printf("Location: %f %f\n", loc[0], loc[1]);
}
RNA_END;
2008-12-26 20:38:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
2007-07-09 20:42:14 +00:00
|
|
|
newp->len = prop->len;
|
|
|
|
|
newp->subtype = prop->subtype;
|
|
|
|
|
newp->totallen = prop->totallen;
|
|
|
|
|
|
|
|
|
|
return newp;
|
|
|
|
|
}
|
2021-12-14 15:49:31 +11:00
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name String Functions (IDProperty String API)
|
|
|
|
|
* \{ */
|
2013-09-05 04:26:08 +00:00
|
|
|
|
2024-06-13 19:02:41 +02:00
|
|
|
IDProperty *IDP_NewStringMaxSize(const char *st,
|
|
|
|
|
const size_t st_maxncpy,
|
2024-10-10 03:17:15 +02:00
|
|
|
const blender::StringRef name,
|
2024-06-13 19:02:41 +02:00
|
|
|
const eIDPropertyFlag flags)
|
2010-06-12 17:30:21 +00:00
|
|
|
{
|
2025-03-20 11:25:19 +01:00
|
|
|
IDProperty *prop = MEM_callocN<IDProperty>("IDProperty string");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (st == nullptr) {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(DEFAULT_ALLOC_FOR_NULL_STRINGS,
|
|
|
|
|
"id property string 1");
|
2013-09-05 04:26:08 +00:00
|
|
|
*IDP_String(prop) = '\0';
|
2010-06-12 17:30:21 +00:00
|
|
|
prop->totallen = DEFAULT_ALLOC_FOR_NULL_STRINGS;
|
2023-07-17 10:46:26 +02:00
|
|
|
prop->len = 1; /* nullptr string, has len of 1 to account for null byte. */
|
2010-06-12 17:30:21 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2014-02-15 12:31:58 +11:00
|
|
|
/* include null terminator '\0' */
|
2023-12-05 16:31:54 +11:00
|
|
|
const int stlen = int((st_maxncpy > 0) ? BLI_strnlen(st, st_maxncpy - 1) : strlen(st)) + 1;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(size_t(stlen), "id property string 2");
|
2010-06-12 17:30:21 +00:00
|
|
|
prop->len = prop->totallen = stlen;
|
2023-12-05 16:31:54 +11:00
|
|
|
|
|
|
|
|
/* Ensured above, must always be true otherwise null terminator assignment will be invalid. */
|
|
|
|
|
BLI_assert(stlen > 0);
|
|
|
|
|
if (stlen > 1) {
|
2023-07-18 14:18:07 +10:00
|
|
|
memcpy(prop->data.pointer, st, size_t(stlen));
|
2023-05-02 15:07:55 +10:00
|
|
|
}
|
2023-12-05 16:31:54 +11:00
|
|
|
IDP_String(prop)[stlen - 1] = '\0';
|
2010-06-12 17:30:21 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-06-12 17:30:21 +00:00
|
|
|
prop->type = IDP_STRING;
|
2025-01-29 12:12:27 +01:00
|
|
|
name.copy_utf8_truncated(prop->name);
|
2024-06-13 19:02:41 +02:00
|
|
|
prop->flag = short(flags);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-06-12 17:30:21 +00:00
|
|
|
return prop;
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-10 03:17:15 +02:00
|
|
|
IDProperty *IDP_NewString(const char *st,
|
|
|
|
|
const blender::StringRef name,
|
|
|
|
|
const eIDPropertyFlag flags)
|
2023-05-02 15:07:55 +10:00
|
|
|
{
|
2024-06-13 19:02:41 +02:00
|
|
|
return IDP_NewStringMaxSize(st, 0, name, flags);
|
2023-05-02 15:07:55 +10:00
|
|
|
}
|
|
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
static IDProperty *IDP_CopyString(const IDProperty *prop, const int flag)
|
2007-07-09 20:42:14 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_STRING);
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *newp = idp_generic_copy(prop, flag);
|
2007-07-09 20:42:14 +00:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (prop->data.pointer) {
|
2013-09-30 11:27:03 +00:00
|
|
|
newp->data.pointer = MEM_dupallocN(prop->data.pointer);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2007-07-09 20:42:14 +00:00
|
|
|
newp->len = prop->len;
|
|
|
|
|
newp->subtype = prop->subtype;
|
|
|
|
|
newp->totallen = prop->totallen;
|
|
|
|
|
|
|
|
|
|
return newp;
|
|
|
|
|
}
|
|
|
|
|
|
2023-12-05 16:31:54 +11:00
|
|
|
void IDP_AssignStringMaxSize(IDProperty *prop, const char *st, const size_t st_maxncpy)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2024-11-02 17:27:09 +11:00
|
|
|
/* FIXME: This function is broken for bytes (in case there are null chars in it),
|
|
|
|
|
* needs a dedicated function which takes directly the size of the byte buffer. */
|
|
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_STRING);
|
2023-05-02 15:07:55 +10:00
|
|
|
const bool is_byte = prop->subtype == IDP_STRING_SUB_BYTE;
|
2023-12-05 16:31:54 +11:00
|
|
|
const int stlen = int((st_maxncpy > 0) ? BLI_strnlen(st, st_maxncpy - 1) : strlen(st)) +
|
|
|
|
|
(is_byte ? 0 : 1);
|
2023-05-02 15:07:55 +10:00
|
|
|
IDP_ResizeArray(prop, stlen);
|
|
|
|
|
if (stlen > 0) {
|
2023-07-18 14:18:07 +10:00
|
|
|
memcpy(prop->data.pointer, st, size_t(stlen));
|
2023-05-02 15:07:55 +10:00
|
|
|
if (is_byte == false) {
|
|
|
|
|
IDP_String(prop)[stlen - 1] = '\0';
|
|
|
|
|
}
|
2011-11-15 09:12:10 +00:00
|
|
|
}
|
2023-05-02 15:07:55 +10:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void IDP_AssignString(IDProperty *prop, const char *st)
|
|
|
|
|
{
|
2024-11-02 17:27:09 +11:00
|
|
|
/* FIXME: Should never be called for `byte` subtype, needs an assert. */
|
|
|
|
|
|
2023-05-02 15:07:55 +10:00
|
|
|
IDP_AssignStringMaxSize(prop, st, 0);
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void IDP_FreeString(IDProperty *prop)
|
|
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_STRING);
|
|
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (prop->data.pointer) {
|
2008-12-31 13:16:37 +00:00
|
|
|
MEM_freeN(prop->data.pointer);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
2023-12-15 10:20:44 +01:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Enum Type (IDProperty Enum API)
|
|
|
|
|
* \{ */
|
|
|
|
|
|
|
|
|
|
static void IDP_int_ui_data_free_enum_items(IDPropertyUIDataInt *ui_data)
|
|
|
|
|
{
|
|
|
|
|
for (const int64_t i : blender::IndexRange(ui_data->enum_items_num)) {
|
|
|
|
|
IDPropertyUIDataEnumItem &item = ui_data->enum_items[i];
|
|
|
|
|
MEM_SAFE_FREE(item.identifier);
|
|
|
|
|
MEM_SAFE_FREE(item.name);
|
|
|
|
|
MEM_SAFE_FREE(item.description);
|
|
|
|
|
}
|
|
|
|
|
MEM_SAFE_FREE(ui_data->enum_items);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const IDPropertyUIDataEnumItem *IDP_EnumItemFind(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(prop->type == IDP_INT);
|
|
|
|
|
const IDPropertyUIDataInt *ui_data = reinterpret_cast<const IDPropertyUIDataInt *>(
|
|
|
|
|
prop->ui_data);
|
|
|
|
|
|
|
|
|
|
const int value = IDP_Int(prop);
|
|
|
|
|
for (const IDPropertyUIDataEnumItem &item :
|
|
|
|
|
blender::Span(ui_data->enum_items, ui_data->enum_items_num))
|
|
|
|
|
{
|
|
|
|
|
if (item.value == value) {
|
|
|
|
|
return &item;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool IDP_EnumItemsValidate(const IDPropertyUIDataEnumItem *items,
|
|
|
|
|
const int items_num,
|
|
|
|
|
void (*error_fn)(const char *))
|
|
|
|
|
{
|
|
|
|
|
blender::Set<int> used_values;
|
|
|
|
|
blender::Set<const char *> used_identifiers;
|
|
|
|
|
used_values.reserve(items_num);
|
|
|
|
|
used_identifiers.reserve(items_num);
|
|
|
|
|
|
|
|
|
|
bool is_valid = true;
|
|
|
|
|
for (const int64_t i : blender::IndexRange(items_num)) {
|
|
|
|
|
const IDPropertyUIDataEnumItem &item = items[i];
|
|
|
|
|
if (item.identifier == nullptr || item.identifier[0] == '\0') {
|
|
|
|
|
if (error_fn) {
|
|
|
|
|
const std::string msg = "Item identifier is empty";
|
|
|
|
|
error_fn(msg.c_str());
|
|
|
|
|
}
|
|
|
|
|
is_valid = false;
|
|
|
|
|
}
|
|
|
|
|
if (!used_identifiers.add(item.identifier)) {
|
|
|
|
|
if (error_fn) {
|
|
|
|
|
const std::string msg = fmt::format("Item identifier '{}' is already used",
|
|
|
|
|
item.identifier);
|
|
|
|
|
error_fn(msg.c_str());
|
|
|
|
|
}
|
|
|
|
|
is_valid = false;
|
|
|
|
|
}
|
|
|
|
|
if (!used_values.add(item.value)) {
|
|
|
|
|
if (error_fn) {
|
|
|
|
|
const std::string msg = fmt::format(
|
|
|
|
|
"Item value {} for item '{}' is already used", item.value, item.identifier);
|
|
|
|
|
error_fn(msg.c_str());
|
|
|
|
|
}
|
|
|
|
|
is_valid = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return is_valid;
|
|
|
|
|
}
|
2021-12-14 15:49:31 +11:00
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/** \} */
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/* -------------------------------------------------------------------- */
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
/** \name ID Type (IDProperty ID API)
|
2013-09-30 11:27:03 +00:00
|
|
|
* \{ */
|
2006-11-17 04:46:48 +00:00
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
static IDProperty *IDP_CopyID(const IDProperty *prop, const int flag)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
BLI_assert(prop->type == IDP_ID);
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *newp = idp_generic_copy(prop, flag);
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
|
|
|
|
|
newp->data.pointer = prop->data.pointer;
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
if ((flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0) {
|
|
|
|
|
id_us_plus(IDP_Id(newp));
|
|
|
|
|
}
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
|
|
|
|
|
return newp;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
|
2020-01-24 11:26:02 +01:00
|
|
|
void IDP_AssignID(IDProperty *prop, ID *id, const int flag)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(prop->type == IDP_ID);
|
2024-08-21 18:16:59 +02:00
|
|
|
/* Do not assign embedded IDs to IDProperties. */
|
|
|
|
|
BLI_assert(!id || (id->flag & ID_FLAG_EMBEDDED_DATA) == 0);
|
2020-01-24 11:26:02 +01:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if ((flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0 && IDP_Id(prop) != nullptr) {
|
2020-01-24 11:26:02 +01:00
|
|
|
id_us_min(IDP_Id(prop));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prop->data.pointer = id;
|
|
|
|
|
|
|
|
|
|
if ((flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0) {
|
|
|
|
|
id_us_plus(IDP_Id(prop));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Group Functions (IDProperty Group API)
|
|
|
|
|
* \{ */
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Checks if a property with the same name as prop exists, and if so replaces it.
|
|
|
|
|
*/
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
static IDProperty *IDP_CopyGroup(const IDProperty *prop, const int flag)
|
2007-07-09 20:42:14 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_GROUP);
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *newp = idp_generic_copy(prop, flag);
|
2013-09-30 11:27:03 +00:00
|
|
|
newp->len = prop->len;
|
2017-03-30 17:01:23 +02:00
|
|
|
newp->subtype = prop->subtype;
|
2013-09-30 11:27:03 +00:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, link, &prop->data.group) {
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
BLI_addtail(&newp->data.group, IDP_CopyProperty_ex(link, flag));
|
2007-07-09 20:42:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return newp;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-12 21:57:37 +11:00
|
|
|
void IDP_SyncGroupValues(IDProperty *dest, const IDProperty *src)
|
2010-02-15 18:43:54 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(dest->type == IDP_GROUP);
|
|
|
|
|
BLI_assert(src->type == IDP_GROUP);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, prop, &src->data.group) {
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty *other = static_cast<IDProperty *>(
|
|
|
|
|
BLI_findstring(&dest->data.group, prop->name, offsetof(IDProperty, name)));
|
2012-05-06 17:22:54 +00:00
|
|
|
if (other && prop->type == other->type) {
|
2011-05-01 06:34:40 +00:00
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
case IDP_FLOAT:
|
|
|
|
|
case IDP_DOUBLE:
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2012-05-06 17:22:54 +00:00
|
|
|
other->data = prop->data;
|
2011-05-01 06:34:40 +00:00
|
|
|
break;
|
|
|
|
|
case IDP_GROUP:
|
|
|
|
|
IDP_SyncGroupValues(other, prop);
|
|
|
|
|
break;
|
|
|
|
|
default: {
|
2017-04-09 16:07:09 +10:00
|
|
|
BLI_insertlinkreplace(&dest->data.group, other, IDP_CopyProperty(prop));
|
|
|
|
|
IDP_FreeProperty(other);
|
2013-07-21 08:16:37 +00:00
|
|
|
break;
|
2010-02-15 18:43:54 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
void IDP_SyncGroupTypes(IDProperty *dest, const IDProperty *src, const bool do_arraylen)
|
2013-12-13 00:28:35 +11:00
|
|
|
{
|
2021-05-05 18:42:41 +02:00
|
|
|
LISTBASE_FOREACH_MUTABLE (IDProperty *, prop_dst, &dest->data.group) {
|
2021-01-25 23:47:56 -06:00
|
|
|
const IDProperty *prop_src = IDP_GetPropertyFromGroup((IDProperty *)src, prop_dst->name);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop_src != nullptr) {
|
2013-12-13 00:28:35 +11:00
|
|
|
/* check of we should replace? */
|
|
|
|
|
if ((prop_dst->type != prop_src->type || prop_dst->subtype != prop_src->subtype) ||
|
|
|
|
|
(do_arraylen && ELEM(prop_dst->type, IDP_ARRAY, IDP_IDPARRAY) &&
|
|
|
|
|
(prop_src->len != prop_dst->len)))
|
|
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
BLI_insertlinkreplace(&dest->data.group, prop_dst, IDP_CopyProperty(prop_src));
|
2017-04-09 16:07:09 +10:00
|
|
|
IDP_FreeProperty(prop_dst);
|
2013-12-13 00:28:35 +11:00
|
|
|
}
|
|
|
|
|
else if (prop_dst->type == IDP_GROUP) {
|
|
|
|
|
IDP_SyncGroupTypes(prop_dst, prop_src, do_arraylen);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2020-09-04 20:59:13 +02:00
|
|
|
IDP_FreeFromGroup(dest, prop_dst);
|
2013-12-13 00:28:35 +11:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-12 21:57:37 +11:00
|
|
|
void IDP_ReplaceGroupInGroup(IDProperty *dest, const IDProperty *src)
|
2010-01-05 03:29:41 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(dest->type == IDP_GROUP);
|
|
|
|
|
BLI_assert(src->type == IDP_GROUP);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, prop, &src->data.group) {
|
|
|
|
|
IDProperty *loop;
|
2023-07-17 10:46:26 +02:00
|
|
|
for (loop = static_cast<IDProperty *>(dest->data.group.first); loop; loop = loop->next) {
|
2013-03-10 06:18:03 +00:00
|
|
|
if (STREQ(loop->name, prop->name)) {
|
2017-04-09 16:07:09 +10:00
|
|
|
BLI_insertlinkreplace(&dest->data.group, loop, IDP_CopyProperty(prop));
|
2010-01-05 03:29:41 +00:00
|
|
|
IDP_FreeProperty(loop);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2010-01-21 21:01:18 +00:00
|
|
|
/* only add at end if not added yet */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (loop == nullptr) {
|
2010-01-21 21:01:18 +00:00
|
|
|
IDProperty *copy = IDP_CopyProperty(prop);
|
|
|
|
|
dest->len++;
|
|
|
|
|
BLI_addtail(&dest->data.group, copy);
|
|
|
|
|
}
|
2010-01-05 03:29:41 +00:00
|
|
|
}
|
|
|
|
|
}
|
2013-03-24 01:51:54 +00:00
|
|
|
|
2025-05-22 09:19:21 +02:00
|
|
|
void IDP_ReplaceInGroup_ex(IDProperty *group,
|
|
|
|
|
IDProperty *prop,
|
|
|
|
|
IDProperty *prop_exist,
|
|
|
|
|
const int flag)
|
2007-05-22 04:41:21 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(group->type == IDP_GROUP);
|
2014-11-10 17:10:58 +01:00
|
|
|
BLI_assert(prop_exist == IDP_GetPropertyFromGroup(group, prop->name));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop_exist != nullptr) {
|
2017-04-09 16:07:09 +10:00
|
|
|
BLI_insertlinkreplace(&group->data.group, prop_exist, prop);
|
2025-05-22 09:19:21 +02:00
|
|
|
IDP_FreeProperty_ex(prop_exist, (flag & LIB_ID_CREATE_NO_USER_REFCOUNT) == 0);
|
2010-08-13 06:30:04 +00:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
group->len++;
|
|
|
|
|
BLI_addtail(&group->data.group, prop);
|
2007-05-22 04:41:21 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-11-10 17:10:58 +01:00
|
|
|
void IDP_ReplaceInGroup(IDProperty *group, IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
IDProperty *prop_exist = IDP_GetPropertyFromGroup(group, prop->name);
|
|
|
|
|
|
2025-05-22 09:19:21 +02:00
|
|
|
IDP_ReplaceInGroup_ex(group, prop, prop_exist, 0);
|
2014-11-10 17:10:58 +01:00
|
|
|
}
|
|
|
|
|
|
2017-08-15 16:42:20 +02:00
|
|
|
void IDP_MergeGroup_ex(IDProperty *dest,
|
|
|
|
|
const IDProperty *src,
|
|
|
|
|
const bool do_overwrite,
|
|
|
|
|
const int flag)
|
2012-10-31 19:07:25 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(dest->type == IDP_GROUP);
|
|
|
|
|
BLI_assert(src->type == IDP_GROUP);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-31 19:07:25 +00:00
|
|
|
if (do_overwrite) {
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, prop, &src->data.group) {
|
2017-05-03 11:37:24 +02:00
|
|
|
if (prop->type == IDP_GROUP) {
|
|
|
|
|
IDProperty *prop_exist = IDP_GetPropertyFromGroup(dest, prop->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop_exist != nullptr) {
|
2017-08-15 16:42:20 +02:00
|
|
|
IDP_MergeGroup_ex(prop_exist, prop, do_overwrite, flag);
|
2017-05-03 11:37:24 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-08-15 16:42:20 +02:00
|
|
|
IDProperty *copy = IDP_CopyProperty_ex(prop, flag);
|
2025-05-22 09:19:21 +02:00
|
|
|
IDP_ReplaceInGroup_ex(dest, copy, IDP_GetPropertyFromGroup(dest, copy->name), flag);
|
2012-10-31 19:07:25 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, prop, &src->data.group) {
|
2017-05-03 11:37:24 +02:00
|
|
|
IDProperty *prop_exist = IDP_GetPropertyFromGroup(dest, prop->name);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop_exist != nullptr) {
|
2017-05-03 11:37:24 +02:00
|
|
|
if (prop->type == IDP_GROUP) {
|
2017-08-15 16:42:20 +02:00
|
|
|
IDP_MergeGroup_ex(prop_exist, prop, do_overwrite, flag);
|
2017-05-03 11:37:24 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2017-08-15 16:42:20 +02:00
|
|
|
IDProperty *copy = IDP_CopyProperty_ex(prop, flag);
|
2012-10-31 19:07:25 +00:00
|
|
|
dest->len++;
|
|
|
|
|
BLI_addtail(&dest->data.group, copy);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-15 16:42:20 +02:00
|
|
|
void IDP_MergeGroup(IDProperty *dest, const IDProperty *src, const bool do_overwrite)
|
|
|
|
|
{
|
|
|
|
|
IDP_MergeGroup_ex(dest, src, do_overwrite, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-12 21:57:37 +11:00
|
|
|
bool IDP_AddToGroup(IDProperty *group, IDProperty *prop)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(group->type == IDP_GROUP);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (IDP_GetPropertyFromGroup(group, prop->name) == nullptr) {
|
2010-08-13 06:30:04 +00:00
|
|
|
group->len++;
|
|
|
|
|
BLI_addtail(&group->data.group, prop);
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2006-11-17 08:19:58 +00:00
|
|
|
}
|
|
|
|
|
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
|
2013-12-12 21:57:37 +11:00
|
|
|
bool IDP_InsertToGroup(IDProperty *group, IDProperty *previous, IDProperty *pnew)
|
2006-12-16 23:54:45 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(group->type == IDP_GROUP);
|
|
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (IDP_GetPropertyFromGroup(group, pnew->name) == nullptr) {
|
2010-08-13 06:30:04 +00:00
|
|
|
group->len++;
|
2013-02-22 14:12:55 +00:00
|
|
|
BLI_insertlinkafter(&group->data.group, previous, pnew);
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2006-12-16 23:54:45 +00:00
|
|
|
}
|
2008-10-06 10:24:32 +00:00
|
|
|
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2006-12-16 23:54:45 +00:00
|
|
|
}
|
|
|
|
|
|
2013-10-16 05:29:28 +00:00
|
|
|
void IDP_RemoveFromGroup(IDProperty *group, IDProperty *prop)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(group->type == IDP_GROUP);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
BLI_assert(BLI_findindex(&group->data.group, prop) != -1);
|
2013-09-30 11:27:03 +00:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
group->len--;
|
|
|
|
|
BLI_remlink(&group->data.group, prop);
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-16 05:29:28 +00:00
|
|
|
void IDP_FreeFromGroup(IDProperty *group, IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
IDP_RemoveFromGroup(group, prop);
|
|
|
|
|
IDP_FreeProperty(prop);
|
|
|
|
|
}
|
|
|
|
|
|
2024-10-10 03:17:15 +02:00
|
|
|
IDProperty *IDP_GetPropertyFromGroup(const IDProperty *prop, const blender::StringRef name)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_GROUP);
|
2024-10-10 03:17:15 +02:00
|
|
|
return BLI_listbase_find<IDProperty>(prop->data.group,
|
|
|
|
|
[&](const IDProperty &elem) { return elem.name == name; });
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
2024-10-10 03:17:15 +02:00
|
|
|
IDProperty *IDP_GetPropertyTypeFromGroup(const IDProperty *prop,
|
|
|
|
|
const blender::StringRef name,
|
|
|
|
|
const char type)
|
2011-02-07 05:05:41 +00:00
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
IDProperty *idprop = IDP_GetPropertyFromGroup(prop, name);
|
2023-07-17 10:46:26 +02:00
|
|
|
return (idprop && idprop->type == type) ? idprop : nullptr;
|
2011-02-07 05:05:41 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-03 20:19:11 +00:00
|
|
|
/* Ok, the way things work, Groups free the ID Property structs of their children.
|
|
|
|
|
* This is because all ID Property freeing functions free only direct data (not the ID Property
|
|
|
|
|
* struct itself), but for Groups the child properties *are* considered
|
|
|
|
|
* direct data. */
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
static void IDP_FreeGroup(IDProperty *prop, const bool do_id_user)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2013-09-30 11:27:03 +00:00
|
|
|
BLI_assert(prop->type == IDP_GROUP);
|
2021-01-25 23:47:56 -06:00
|
|
|
|
|
|
|
|
LISTBASE_FOREACH (IDProperty *, loop, &prop->data.group) {
|
2019-05-16 14:17:11 +02:00
|
|
|
IDP_FreePropertyContent_ex(loop, do_id_user);
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
2010-01-21 21:01:18 +00:00
|
|
|
BLI_freelistN(&prop->data.group);
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
2021-12-14 15:49:31 +11:00
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/** \} */
|
2006-11-17 04:46:48 +00:00
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
|
/** \name Main Functions (IDProperty Main API)
|
|
|
|
|
* \{ */
|
2020-10-27 21:32:09 +11:00
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
int IDP_coerce_to_int_or_zero(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
return IDP_Int(prop);
|
|
|
|
|
case IDP_DOUBLE:
|
2023-07-18 14:18:07 +10:00
|
|
|
return int(IDP_Double(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_FLOAT:
|
2023-07-18 14:18:07 +10:00
|
|
|
return int(IDP_Float(prop));
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2023-07-18 14:18:07 +10:00
|
|
|
return int(IDP_Bool(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
double IDP_coerce_to_double_or_zero(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_DOUBLE:
|
|
|
|
|
return IDP_Double(prop);
|
|
|
|
|
case IDP_FLOAT:
|
2023-07-18 14:18:07 +10:00
|
|
|
return double(IDP_Float(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_INT:
|
2023-07-18 14:18:07 +10:00
|
|
|
return double(IDP_Int(prop));
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2023-07-18 14:18:07 +10:00
|
|
|
return double(IDP_Bool(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
default:
|
|
|
|
|
return 0.0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
float IDP_coerce_to_float_or_zero(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_FLOAT:
|
|
|
|
|
return IDP_Float(prop);
|
|
|
|
|
case IDP_DOUBLE:
|
2023-07-18 14:18:07 +10:00
|
|
|
return float(IDP_Double(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_INT:
|
2023-07-18 14:18:07 +10:00
|
|
|
return float(IDP_Int(prop));
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2023-07-18 14:18:07 +10:00
|
|
|
return float(IDP_Bool(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
default:
|
|
|
|
|
return 0.0f;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
IDProperty *IDP_CopyProperty_ex(const IDProperty *prop, const int flag)
|
2007-07-09 20:42:14 +00:00
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
case IDP_GROUP:
|
|
|
|
|
return IDP_CopyGroup(prop, flag);
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
return IDP_CopyString(prop, flag);
|
|
|
|
|
case IDP_ID:
|
|
|
|
|
return IDP_CopyID(prop, flag);
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
return IDP_CopyArray(prop, flag);
|
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
|
return IDP_CopyIDPArray(prop, flag);
|
|
|
|
|
default:
|
|
|
|
|
return idp_generic_copy(prop, flag);
|
2007-07-09 20:42:14 +00:00
|
|
|
}
|
|
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
|
Refactor ID copying (and to some extent, ID freeing).
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
2017-08-07 16:39:55 +02:00
|
|
|
IDProperty *IDP_CopyProperty(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
return IDP_CopyProperty_ex(prop, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2023-03-30 18:49:24 -04:00
|
|
|
void IDP_CopyPropertyContent(IDProperty *dst, const IDProperty *src)
|
2020-09-18 15:11:31 +02:00
|
|
|
{
|
|
|
|
|
IDProperty *idprop_tmp = IDP_CopyProperty(src);
|
|
|
|
|
idprop_tmp->prev = dst->prev;
|
|
|
|
|
idprop_tmp->next = dst->next;
|
2024-01-31 21:12:16 -05:00
|
|
|
std::swap(*dst, *idprop_tmp);
|
2020-09-18 15:11:31 +02:00
|
|
|
IDP_FreeProperty(idprop_tmp);
|
|
|
|
|
}
|
|
|
|
|
|
2023-09-17 12:16:40 +10:00
|
|
|
IDProperty *IDP_GetProperties(ID *id)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2023-09-17 12:16:40 +10:00
|
|
|
return id->properties;
|
|
|
|
|
}
|
2020-08-07 12:30:43 +02:00
|
|
|
|
2023-09-17 12:16:40 +10:00
|
|
|
IDProperty *IDP_EnsureProperties(ID *id)
|
|
|
|
|
{
|
|
|
|
|
if (id->properties == nullptr) {
|
2025-03-20 11:25:19 +01:00
|
|
|
id->properties = MEM_callocN<IDProperty>("IDProperty");
|
2020-08-07 12:30:43 +02:00
|
|
|
id->properties->type = IDP_GROUP;
|
2023-02-09 11:30:25 +11:00
|
|
|
/* NOTE(@ideasman42): Don't overwrite the data's name and type
|
2020-08-07 12:30:43 +02:00
|
|
|
* some functions might need this if they
|
2021-06-26 21:35:18 +10:00
|
|
|
* don't have a real ID, should be named elsewhere. */
|
2023-06-19 20:06:55 +10:00
|
|
|
// STRNCPY(id->name, "top_level_group");
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
2020-08-07 12:30:43 +02:00
|
|
|
return id->properties;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
|
2023-03-30 18:49:24 -04:00
|
|
|
bool IDP_EqualsProperties_ex(const IDProperty *prop1,
|
|
|
|
|
const IDProperty *prop2,
|
|
|
|
|
const bool is_strict)
|
2009-01-28 23:29:27 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop1 == nullptr && prop2 == nullptr) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop1 == nullptr || prop2 == nullptr) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return is_strict ? false : true;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2020-08-07 12:30:43 +02:00
|
|
|
if (prop1->type != prop2->type) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-31 19:42:02 +00:00
|
|
|
switch (prop1->type) {
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
return (IDP_Int(prop1) == IDP_Int(prop2));
|
|
|
|
|
case IDP_FLOAT:
|
2014-08-11 20:58:42 +06:00
|
|
|
#if !defined(NDEBUG) && defined(WITH_PYTHON)
|
2014-04-24 16:46:54 +02:00
|
|
|
{
|
|
|
|
|
float p1 = IDP_Float(prop1);
|
|
|
|
|
float p2 = IDP_Float(prop2);
|
2025-02-16 20:56:07 +11:00
|
|
|
if ((p1 != p2) && ((fabsf(p1 - p2) / max_ff(fabsf(p1), fabsf(p2))) < 0.001f)) {
|
2014-04-24 16:46:54 +02:00
|
|
|
printf(
|
|
|
|
|
"WARNING: Comparing two float properties that have nearly the same value (%f vs. "
|
|
|
|
|
"%f)\n",
|
|
|
|
|
p1,
|
|
|
|
|
p2);
|
|
|
|
|
printf(" p1: ");
|
2018-05-04 07:26:42 +02:00
|
|
|
IDP_print(prop1);
|
2014-04-24 16:46:54 +02:00
|
|
|
printf(" p2: ");
|
2018-05-04 07:26:42 +02:00
|
|
|
IDP_print(prop2);
|
2014-04-24 16:46:54 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2012-10-31 19:42:02 +00:00
|
|
|
return (IDP_Float(prop1) == IDP_Float(prop2));
|
|
|
|
|
case IDP_DOUBLE:
|
|
|
|
|
return (IDP_Double(prop1) == IDP_Double(prop2));
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
|
|
|
|
return (IDP_Bool(prop1) == IDP_Bool(prop2));
|
2012-10-31 19:42:02 +00:00
|
|
|
case IDP_STRING: {
|
2022-09-25 15:14:13 +10:00
|
|
|
return ((prop1->len == prop2->len) &&
|
2023-07-18 14:18:07 +10:00
|
|
|
STREQLEN(IDP_String(prop1), IDP_String(prop2), size_t(prop1->len)));
|
2014-12-12 16:17:52 +01:00
|
|
|
}
|
2012-10-31 19:42:02 +00:00
|
|
|
case IDP_ARRAY:
|
|
|
|
|
if (prop1->len == prop2->len && prop1->subtype == prop2->subtype) {
|
2014-12-12 16:17:52 +01:00
|
|
|
return (memcmp(IDP_Array(prop1),
|
|
|
|
|
IDP_Array(prop2),
|
2023-07-20 11:30:25 +10:00
|
|
|
idp_size_table[int(prop1->subtype)] * size_t(prop1->len)) == 0);
|
2012-10-31 19:42:02 +00:00
|
|
|
}
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2012-10-31 19:42:02 +00:00
|
|
|
case IDP_GROUP: {
|
2019-04-22 09:39:35 +10:00
|
|
|
if (is_strict && prop1->len != prop2->len) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2023-03-30 18:49:24 -04:00
|
|
|
LISTBASE_FOREACH (const IDProperty *, link1, &prop1->data.group) {
|
|
|
|
|
const IDProperty *link2 = IDP_GetPropertyFromGroup(prop2, link1->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (!IDP_EqualsProperties_ex(link1, link2, is_strict)) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2012-10-31 19:42:02 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2012-10-31 19:42:02 +00:00
|
|
|
}
|
|
|
|
|
case IDP_IDPARRAY: {
|
2023-03-30 18:49:24 -04:00
|
|
|
const IDProperty *array1 = IDP_IDPArray(prop1);
|
|
|
|
|
const IDProperty *array2 = IDP_IDPArray(prop2);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:39:35 +10:00
|
|
|
if (prop1->len != prop2->len) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = 0; i < prop1->len; i++) {
|
2019-04-22 09:39:35 +10:00
|
|
|
if (!IDP_EqualsProperties_ex(&array1[i], &array2[i], is_strict)) {
|
2014-11-15 21:28:29 +01:00
|
|
|
return false;
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2018-03-14 18:05:09 +01:00
|
|
|
}
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2012-10-31 19:42:02 +00:00
|
|
|
}
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
case IDP_ID:
|
|
|
|
|
return (IDP_Id(prop1) == IDP_Id(prop2));
|
2012-10-31 19:42:02 +00:00
|
|
|
default:
|
2022-05-17 15:08:18 +02:00
|
|
|
BLI_assert_unreachable();
|
2012-10-31 19:42:02 +00:00
|
|
|
break;
|
2009-01-28 23:29:27 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-11-15 21:28:29 +01:00
|
|
|
return true;
|
2009-01-28 23:29:27 +00:00
|
|
|
}
|
|
|
|
|
|
2023-03-30 18:49:24 -04:00
|
|
|
bool IDP_EqualsProperties(const IDProperty *prop1, const IDProperty *prop2)
|
2012-10-31 20:29:32 +00:00
|
|
|
{
|
2014-04-01 11:34:00 +11:00
|
|
|
return IDP_EqualsProperties_ex(prop1, prop2, true);
|
2012-10-31 20:29:32 +00:00
|
|
|
}
|
|
|
|
|
|
2024-06-13 19:02:41 +02:00
|
|
|
IDProperty *IDP_New(const char type,
|
|
|
|
|
const IDPropertyTemplate *val,
|
2024-10-10 03:17:15 +02:00
|
|
|
const blender::StringRef name,
|
2024-06-13 19:02:41 +02:00
|
|
|
const eIDPropertyFlag flags)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty *prop = nullptr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
switch (type) {
|
|
|
|
|
case IDP_INT:
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty int");
|
2011-11-15 09:22:52 +00:00
|
|
|
prop->data.val = val->i;
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
|
|
|
|
case IDP_FLOAT:
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty float");
|
2012-05-06 17:22:54 +00:00
|
|
|
*(float *)&prop->data.val = val->f;
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
2008-07-24 19:22:17 +00:00
|
|
|
case IDP_DOUBLE:
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty double");
|
2012-05-06 17:22:54 +00:00
|
|
|
*(double *)&prop->data.val = val->d;
|
2012-09-16 04:58:18 +00:00
|
|
|
break;
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty boolean");
|
2023-07-18 14:18:07 +10:00
|
|
|
prop->data.val = bool(val->i);
|
2023-01-13 12:31:27 -06:00
|
|
|
break;
|
2006-11-17 04:46:48 +00:00
|
|
|
case IDP_ARRAY: {
|
2024-06-07 14:47:01 +02:00
|
|
|
/* FIXME: This seems to be the only place in code allowing `IDP_GROUP` as subtype of an
|
|
|
|
|
* `IDP_ARRAY`. This is most likely a mistake. `IDP_GROUP` array should be of type
|
|
|
|
|
* `IDP_IDPARRAY`, as done e.g. in #idp_from_PySequence_Buffer in bpy API. */
|
2023-01-13 12:31:27 -06:00
|
|
|
if (ELEM(val->array.type, IDP_FLOAT, IDP_INT, IDP_DOUBLE, IDP_GROUP, IDP_BOOLEAN)) {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty array");
|
2011-11-15 09:22:52 +00:00
|
|
|
prop->subtype = val->array.type;
|
2014-12-12 16:17:52 +01:00
|
|
|
if (val->array.len) {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_calloc_arrayN(
|
|
|
|
|
size_t(val->array.len), idp_size_table[val->array.type], "id property array");
|
2014-12-12 16:17:52 +01:00
|
|
|
}
|
2011-11-15 09:22:52 +00:00
|
|
|
prop->len = prop->totallen = val->array.len;
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
2012-03-24 06:18:31 +00:00
|
|
|
}
|
2019-02-01 12:44:19 +11:00
|
|
|
CLOG_ERROR(&LOG, "bad array type.");
|
2023-07-17 10:46:26 +02:00
|
|
|
return nullptr;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
case IDP_STRING: {
|
2011-11-15 09:22:52 +00:00
|
|
|
const char *st = val->string.str;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty string");
|
2011-11-15 09:22:52 +00:00
|
|
|
if (val->string.subtype == IDP_STRING_SUB_BYTE) {
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: Intentionally not null terminated. */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (st == nullptr) {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(DEFAULT_ALLOC_FOR_NULL_STRINGS,
|
|
|
|
|
"id property string 1");
|
2013-09-05 04:26:08 +00:00
|
|
|
*IDP_String(prop) = '\0';
|
2011-11-15 09:12:10 +00:00
|
|
|
prop->totallen = DEFAULT_ALLOC_FOR_NULL_STRINGS;
|
|
|
|
|
prop->len = 0;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(size_t(val->string.len),
|
|
|
|
|
"id property string 2");
|
2011-11-15 09:22:52 +00:00
|
|
|
prop->len = prop->totallen = val->string.len;
|
2023-07-20 11:30:25 +10:00
|
|
|
memcpy(prop->data.pointer, st, size_t(val->string.len));
|
2011-11-15 09:12:10 +00:00
|
|
|
}
|
2012-05-06 17:22:54 +00:00
|
|
|
prop->subtype = IDP_STRING_SUB_BYTE;
|
2011-11-15 09:12:10 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2023-07-17 10:46:26 +02:00
|
|
|
if (st == nullptr || val->string.len <= 1) {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(DEFAULT_ALLOC_FOR_NULL_STRINGS,
|
|
|
|
|
"id property string 1");
|
2013-09-05 04:26:08 +00:00
|
|
|
*IDP_String(prop) = '\0';
|
2011-11-15 09:12:10 +00:00
|
|
|
prop->totallen = DEFAULT_ALLOC_FOR_NULL_STRINGS;
|
2023-07-17 10:46:26 +02:00
|
|
|
/* nullptr string, has len of 1 to account for null byte. */
|
2018-07-13 10:51:49 +02:00
|
|
|
prop->len = 1;
|
2011-11-15 09:12:10 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2023-07-18 14:18:07 +10:00
|
|
|
BLI_assert(int(val->string.len) <= int(strlen(st)) + 1);
|
2025-03-20 11:25:19 +01:00
|
|
|
prop->data.pointer = MEM_malloc_arrayN<char>(size_t(val->string.len),
|
|
|
|
|
"id property string 3");
|
2023-07-20 11:30:25 +10:00
|
|
|
memcpy(prop->data.pointer, st, size_t(val->string.len) - 1);
|
2016-07-31 16:52:44 +10:00
|
|
|
IDP_String(prop)[val->string.len - 1] = '\0';
|
|
|
|
|
prop->len = prop->totallen = val->string.len;
|
2011-11-15 09:12:10 +00:00
|
|
|
}
|
2012-05-06 17:22:54 +00:00
|
|
|
prop->subtype = IDP_STRING_SUB_UTF8;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_GROUP: {
|
2018-07-13 10:51:49 +02:00
|
|
|
/* Values are set properly by calloc. */
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty group");
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
|
|
|
|
}
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
case IDP_ID: {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty datablock");
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
prop->data.pointer = (void *)val->id;
|
|
|
|
|
prop->type = IDP_ID;
|
|
|
|
|
id_us_plus(IDP_Id(prop));
|
|
|
|
|
break;
|
|
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
default: {
|
2025-03-20 11:25:19 +01:00
|
|
|
prop = MEM_callocN<IDProperty>("IDProperty array");
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
prop->type = type;
|
2025-01-29 12:12:27 +01:00
|
|
|
name.copy_utf8_truncated(prop->name);
|
2024-06-13 19:02:41 +02:00
|
|
|
prop->flag = short(flags);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-11-17 04:46:48 +00:00
|
|
|
return prop;
|
|
|
|
|
}
|
|
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
void IDP_ui_data_free_unique_contents(IDPropertyUIData *ui_data,
|
|
|
|
|
const eIDPropertyUIDataType type,
|
|
|
|
|
const IDPropertyUIData *other)
|
|
|
|
|
{
|
|
|
|
|
if (ui_data->description != other->description) {
|
|
|
|
|
MEM_SAFE_FREE(ui_data->description);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
const IDPropertyUIDataString *other_string = (const IDPropertyUIDataString *)other;
|
|
|
|
|
IDPropertyUIDataString *ui_data_string = (IDPropertyUIDataString *)ui_data;
|
|
|
|
|
if (ui_data_string->default_value != other_string->default_value) {
|
|
|
|
|
MEM_SAFE_FREE(ui_data_string->default_value);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
const IDPropertyUIDataInt *other_int = (const IDPropertyUIDataInt *)other;
|
|
|
|
|
IDPropertyUIDataInt *ui_data_int = (IDPropertyUIDataInt *)ui_data;
|
|
|
|
|
if (ui_data_int->default_array != other_int->default_array) {
|
|
|
|
|
MEM_SAFE_FREE(ui_data_int->default_array);
|
|
|
|
|
}
|
2023-12-15 10:20:44 +01:00
|
|
|
if (ui_data_int->enum_items != other_int->enum_items) {
|
|
|
|
|
IDP_int_ui_data_free_enum_items(ui_data_int);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
const IDPropertyUIDataBool *other_bool = (const IDPropertyUIDataBool *)other;
|
|
|
|
|
IDPropertyUIDataBool *ui_data_bool = (IDPropertyUIDataBool *)ui_data;
|
|
|
|
|
if (ui_data_bool->default_array != other_bool->default_array) {
|
|
|
|
|
MEM_SAFE_FREE(ui_data_bool->default_array);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
const IDPropertyUIDataFloat *other_float = (const IDPropertyUIDataFloat *)other;
|
|
|
|
|
IDPropertyUIDataFloat *ui_data_float = (IDPropertyUIDataFloat *)ui_data;
|
|
|
|
|
if (ui_data_float->default_array != other_float->default_array) {
|
|
|
|
|
MEM_SAFE_FREE(ui_data_float->default_array);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
static void ui_data_free(IDPropertyUIData *ui_data, const eIDPropertyUIDataType type)
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
{
|
2024-03-12 15:49:20 +01:00
|
|
|
switch (type) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
2024-03-12 15:49:20 +01:00
|
|
|
IDPropertyUIDataString *ui_data_string = (IDPropertyUIDataString *)ui_data;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
MEM_SAFE_FREE(ui_data_string->default_value);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
2024-03-12 15:49:20 +01:00
|
|
|
IDPropertyUIDataInt *ui_data_int = (IDPropertyUIDataInt *)ui_data;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
MEM_SAFE_FREE(ui_data_int->default_array);
|
2023-12-15 10:20:44 +01:00
|
|
|
IDP_int_ui_data_free_enum_items(ui_data_int);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
2024-03-12 15:49:20 +01:00
|
|
|
IDPropertyUIDataBool *ui_data_bool = (IDPropertyUIDataBool *)ui_data;
|
2023-01-13 12:31:27 -06:00
|
|
|
MEM_SAFE_FREE(ui_data_bool->default_array);
|
|
|
|
|
break;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
2024-03-12 15:49:20 +01:00
|
|
|
IDPropertyUIDataFloat *ui_data_float = (IDPropertyUIDataFloat *)ui_data;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
MEM_SAFE_FREE(ui_data_float->default_array);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
MEM_SAFE_FREE(ui_data->description);
|
|
|
|
|
|
|
|
|
|
MEM_freeN(ui_data);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
void IDP_ui_data_free(IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
ui_data_free(prop->ui_data, IDP_ui_data_type(prop));
|
2023-07-17 10:46:26 +02:00
|
|
|
prop->ui_data = nullptr;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
|
2019-05-16 14:17:11 +02:00
|
|
|
void IDP_FreePropertyContent_ex(IDProperty *prop, const bool do_id_user)
|
2006-11-17 04:46:48 +00:00
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
IDP_FreeArray(prop);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
IDP_FreeString(prop);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_GROUP:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
IDP_FreeGroup(prop, do_id_user);
|
2006-11-17 04:46:48 +00:00
|
|
|
break;
|
2008-12-31 13:16:37 +00:00
|
|
|
case IDP_IDPARRAY:
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
IDP_FreeIDPArray(prop, do_id_user);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_ID:
|
|
|
|
|
if (do_id_user) {
|
|
|
|
|
id_us_min(IDP_Id(prop));
|
|
|
|
|
}
|
2008-12-31 13:16:37 +00:00
|
|
|
break;
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop->ui_data != nullptr) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
IDP_ui_data_free(prop);
|
|
|
|
|
}
|
2006-11-17 04:46:48 +00:00
|
|
|
}
|
|
|
|
|
|
2019-05-16 14:11:11 +02:00
|
|
|
void IDP_FreePropertyContent(IDProperty *prop)
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
{
|
2019-05-16 14:17:11 +02:00
|
|
|
IDP_FreePropertyContent_ex(prop, true);
|
Datablock ID Properties
The absence of datablock properties "will certainly be resolved soon as the need for them is becoming obvious" said the [[http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes|Python Nodes release notes]]. So this patch allows Python scripts to create ID Properties which reference datablocks.
This functionality is implemented for `PointerProperty` and now such properties can be created with Python.
In addition to the standard update callback, `PointerProperty` can have a `poll` callback (standard RNA) which is useful for search menus. For details see the test included in this patch.
Original author: @artfunkel
Alexander (Blend4Web Team)
Reviewers: brecht, artfunkel, mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: jta, sergey, campbellbarton, wisaac, poseidon4o, mont29, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov, fjuhec, sharlybg, cardboard, duarteframos, blueprintrandom, a.romanov, BYOB, disnel, aditiapratama, bliblubli, dfelinto, lukastoenne
Maniphest Tasks: T37754
Differential Revision: https://developer.blender.org/D113
2017-04-13 12:30:03 +03:00
|
|
|
}
|
|
|
|
|
|
2019-11-04 15:02:03 +01:00
|
|
|
void IDP_FreeProperty_ex(IDProperty *prop, const bool do_id_user)
|
|
|
|
|
{
|
|
|
|
|
IDP_FreePropertyContent_ex(prop, do_id_user);
|
|
|
|
|
MEM_freeN(prop);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-16 14:11:11 +02:00
|
|
|
void IDP_FreeProperty(IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
IDP_FreePropertyContent(prop);
|
|
|
|
|
MEM_freeN(prop);
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-02 23:10:14 +00:00
|
|
|
void IDP_ClearProperty(IDProperty *prop)
|
|
|
|
|
{
|
2019-05-16 14:11:11 +02:00
|
|
|
IDP_FreePropertyContent(prop);
|
2023-07-17 10:46:26 +02:00
|
|
|
prop->data.pointer = nullptr;
|
2013-01-02 23:10:14 +00:00
|
|
|
prop->len = prop->totallen = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-24 15:00:01 +01:00
|
|
|
void IDP_Reset(IDProperty *prop, const IDProperty *reference)
|
|
|
|
|
{
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop == nullptr) {
|
2018-01-24 15:00:01 +01:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
IDP_ClearProperty(prop);
|
2023-07-17 10:46:26 +02:00
|
|
|
if (reference != nullptr) {
|
2018-01-24 15:00:01 +01:00
|
|
|
IDP_MergeGroup(prop, reference, true);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-25 20:58:55 +02:00
|
|
|
void IDP_foreach_property(IDProperty *id_property_root,
|
|
|
|
|
const int type_filter,
|
2024-03-26 13:36:30 -04:00
|
|
|
const blender::FunctionRef<void(IDProperty *id_property)> callback)
|
2020-04-25 20:58:55 +02:00
|
|
|
{
|
|
|
|
|
if (!id_property_root) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (type_filter == 0 || (1 << id_property_root->type) & type_filter) {
|
2024-03-26 13:36:30 -04:00
|
|
|
callback(id_property_root);
|
2020-04-25 20:58:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Recursive call into container types of ID properties. */
|
|
|
|
|
switch (id_property_root->type) {
|
|
|
|
|
case IDP_GROUP: {
|
|
|
|
|
LISTBASE_FOREACH (IDProperty *, loop, &id_property_root->data.group) {
|
2024-03-26 13:36:30 -04:00
|
|
|
IDP_foreach_property(loop, type_filter, callback);
|
2020-04-25 20:58:55 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_IDPARRAY: {
|
2023-07-17 10:46:26 +02:00
|
|
|
IDProperty *loop = static_cast<IDProperty *>(IDP_Array(id_property_root));
|
2020-04-25 20:58:55 +02:00
|
|
|
for (int i = 0; i < id_property_root->len; i++) {
|
2024-03-26 13:36:30 -04:00
|
|
|
IDP_foreach_property(&loop[i], type_filter, callback);
|
2020-04-25 20:58:55 +02:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
default:
|
|
|
|
|
break; /* Nothing to do here with other types of IDProperties... */
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-21 12:45:33 +02:00
|
|
|
void IDP_WriteProperty_OnlyData(const IDProperty *prop, BlendWriter *writer);
|
|
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
static void write_ui_data(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
|
|
|
|
IDPropertyUIData *ui_data = prop->ui_data;
|
|
|
|
|
|
|
|
|
|
BLO_write_string(writer, ui_data->description);
|
|
|
|
|
|
|
|
|
|
switch (IDP_ui_data_type(prop)) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
IDPropertyUIDataString *ui_data_string = (IDPropertyUIDataString *)ui_data;
|
|
|
|
|
BLO_write_string(writer, ui_data_string->default_value);
|
|
|
|
|
BLO_write_struct(writer, IDPropertyUIDataString, ui_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
BLO_write_struct(writer, IDPropertyUIDataID, ui_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
IDPropertyUIDataInt *ui_data_int = (IDPropertyUIDataInt *)ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_write_int32_array(
|
2023-07-18 14:18:07 +10:00
|
|
|
writer, uint(ui_data_int->default_array_len), (int32_t *)ui_data_int->default_array);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
2023-12-15 10:20:44 +01:00
|
|
|
BLO_write_struct_array(
|
|
|
|
|
writer, IDPropertyUIDataEnumItem, ui_data_int->enum_items_num, ui_data_int->enum_items);
|
|
|
|
|
for (const int64_t i : blender::IndexRange(ui_data_int->enum_items_num)) {
|
|
|
|
|
IDPropertyUIDataEnumItem &item = ui_data_int->enum_items[i];
|
|
|
|
|
BLO_write_string(writer, item.identifier);
|
|
|
|
|
BLO_write_string(writer, item.name);
|
|
|
|
|
BLO_write_string(writer, item.description);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
BLO_write_struct(writer, IDPropertyUIDataInt, ui_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
IDPropertyUIDataBool *ui_data_bool = (IDPropertyUIDataBool *)ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_write_int8_array(writer,
|
2023-07-18 14:18:07 +10:00
|
|
|
uint(ui_data_bool->default_array_len),
|
2023-01-13 12:31:27 -06:00
|
|
|
(const int8_t *)ui_data_bool->default_array);
|
|
|
|
|
}
|
|
|
|
|
BLO_write_struct(writer, IDPropertyUIDataBool, ui_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
IDPropertyUIDataFloat *ui_data_float = (IDPropertyUIDataFloat *)ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_write_double_array(
|
2023-07-18 14:18:07 +10:00
|
|
|
writer, uint(ui_data_float->default_array_len), ui_data_float->default_array);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
BLO_write_struct(writer, IDPropertyUIDataFloat, ui_data);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-21 12:45:33 +02:00
|
|
|
static void IDP_WriteArray(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
2021-06-24 15:41:46 +10:00
|
|
|
/* Remember to set #IDProperty.totallen to len in the linking code! */
|
2020-08-21 12:45:33 +02:00
|
|
|
if (prop->data.pointer) {
|
2024-07-31 18:39:45 +02:00
|
|
|
/* Only write the actual data (`prop->len`), not the whole allocated buffer (`prop->totallen`).
|
|
|
|
|
*/
|
|
|
|
|
switch (eIDPropertyType(prop->subtype)) {
|
|
|
|
|
case IDP_GROUP: {
|
|
|
|
|
BLO_write_pointer_array(writer, uint32_t(prop->len), prop->data.pointer);
|
|
|
|
|
|
|
|
|
|
IDProperty **array = static_cast<IDProperty **>(prop->data.pointer);
|
|
|
|
|
for (int i = 0; i < prop->len; i++) {
|
|
|
|
|
IDP_BlendWrite(writer, array[i]);
|
|
|
|
|
}
|
|
|
|
|
break;
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
2024-07-31 18:39:45 +02:00
|
|
|
case IDP_DOUBLE:
|
|
|
|
|
BLO_write_double_array(
|
|
|
|
|
writer, uint32_t(prop->len), static_cast<double *>(prop->data.pointer));
|
|
|
|
|
break;
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
BLO_write_int32_array(writer, uint32_t(prop->len), static_cast<int *>(prop->data.pointer));
|
|
|
|
|
break;
|
|
|
|
|
case IDP_FLOAT:
|
|
|
|
|
BLO_write_float_array(
|
|
|
|
|
writer, uint32_t(prop->len), static_cast<float *>(prop->data.pointer));
|
|
|
|
|
break;
|
|
|
|
|
case IDP_BOOLEAN:
|
|
|
|
|
BLO_write_int8_array(
|
|
|
|
|
writer, uint32_t(prop->len), static_cast<int8_t *>(prop->data.pointer));
|
|
|
|
|
break;
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
case IDP_ID:
|
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
break;
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_WriteIDPArray(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
2021-06-24 15:41:46 +10:00
|
|
|
/* Remember to set #IDProperty.totallen to len in the linking code! */
|
2020-08-21 12:45:33 +02:00
|
|
|
if (prop->data.pointer) {
|
2023-07-17 10:46:26 +02:00
|
|
|
const IDProperty *array = static_cast<const IDProperty *>(prop->data.pointer);
|
2020-08-21 12:45:33 +02:00
|
|
|
|
|
|
|
|
BLO_write_struct_array(writer, IDProperty, prop->len, array);
|
|
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
for (int a = 0; a < prop->len; a++) {
|
2020-08-21 12:45:33 +02:00
|
|
|
IDP_WriteProperty_OnlyData(&array[a], writer);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_WriteString(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
2021-06-24 15:41:46 +10:00
|
|
|
/* Remember to set #IDProperty.totallen to len in the linking code! */
|
2024-07-31 18:30:50 +02:00
|
|
|
/* Do not use #BLO_write_string here, since 'bytes' sub-type of IDProperties may not be
|
|
|
|
|
* null-terminated. */
|
|
|
|
|
BLO_write_char_array(writer, uint(prop->len), static_cast<char *>(prop->data.pointer));
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_WriteGroup(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, loop, &prop->data.group) {
|
2020-08-21 12:45:33 +02:00
|
|
|
IDP_BlendWrite(writer, loop);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Functions to read/write ID Properties */
|
|
|
|
|
void IDP_WriteProperty_OnlyData(const IDProperty *prop, BlendWriter *writer)
|
|
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_GROUP:
|
|
|
|
|
IDP_WriteGroup(prop, writer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
IDP_WriteString(prop, writer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
IDP_WriteArray(prop, writer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
|
IDP_WriteIDPArray(prop, writer);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop->ui_data != nullptr) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
write_ui_data(prop, writer);
|
|
|
|
|
}
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void IDP_BlendWrite(BlendWriter *writer, const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
BLO_write_struct(writer, IDProperty, prop);
|
|
|
|
|
IDP_WriteProperty_OnlyData(prop, writer);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_DirectLinkProperty(IDProperty *prop, BlendDataReader *reader);
|
|
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
static void read_ui_data(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
2024-05-03 11:32:43 +10:00
|
|
|
/* NOTE: null UI data can happen when opening more recent files with unknown types of
|
2024-04-24 17:01:22 +02:00
|
|
|
* IDProperties. */
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
|
|
|
|
switch (IDP_ui_data_type(prop)) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct(reader, IDPropertyUIDataString, &prop->ui_data);
|
|
|
|
|
if (prop->ui_data) {
|
|
|
|
|
IDPropertyUIDataString *ui_data_string = (IDPropertyUIDataString *)prop->ui_data;
|
|
|
|
|
BLO_read_string(reader, &ui_data_string->default_value);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct(reader, IDPropertyUIDataID, &prop->ui_data);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct(reader, IDPropertyUIDataInt, &prop->ui_data);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
IDPropertyUIDataInt *ui_data_int = (IDPropertyUIDataInt *)prop->ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_read_int32_array(
|
2025-01-26 20:07:57 +01:00
|
|
|
reader, ui_data_int->default_array_len, (&ui_data_int->default_array));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
2024-09-23 16:10:50 +10:00
|
|
|
else {
|
|
|
|
|
ui_data_int->default_array = nullptr;
|
|
|
|
|
ui_data_int->default_array_len = 0;
|
|
|
|
|
}
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct_array(reader,
|
|
|
|
|
IDPropertyUIDataEnumItem,
|
|
|
|
|
size_t(ui_data_int->enum_items_num),
|
|
|
|
|
&ui_data_int->enum_items);
|
2023-12-15 10:20:44 +01:00
|
|
|
for (const int64_t i : blender::IndexRange(ui_data_int->enum_items_num)) {
|
|
|
|
|
IDPropertyUIDataEnumItem &item = ui_data_int->enum_items[i];
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_string(reader, &item.identifier);
|
|
|
|
|
BLO_read_string(reader, &item.name);
|
|
|
|
|
BLO_read_string(reader, &item.description);
|
2023-12-15 10:20:44 +01:00
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct(reader, IDPropertyUIDataBool, &prop->ui_data);
|
2023-01-13 12:31:27 -06:00
|
|
|
IDPropertyUIDataBool *ui_data_bool = (IDPropertyUIDataBool *)prop->ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_read_int8_array(
|
2025-01-26 20:07:57 +01:00
|
|
|
reader, ui_data_bool->default_array_len, (&ui_data_bool->default_array));
|
2023-01-13 12:31:27 -06:00
|
|
|
}
|
2024-09-23 16:10:50 +10:00
|
|
|
else {
|
|
|
|
|
ui_data_bool->default_array = nullptr;
|
|
|
|
|
ui_data_bool->default_array_len = 0;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
break;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct(reader, IDPropertyUIDataFloat, &prop->ui_data);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
IDPropertyUIDataFloat *ui_data_float = (IDPropertyUIDataFloat *)prop->ui_data;
|
|
|
|
|
if (prop->type == IDP_ARRAY) {
|
|
|
|
|
BLO_read_double_array(
|
2025-01-26 20:07:57 +01:00
|
|
|
reader, ui_data_float->default_array_len, (&ui_data_float->default_array));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
2024-09-23 16:10:50 +10:00
|
|
|
else {
|
|
|
|
|
ui_data_float->default_array = nullptr;
|
|
|
|
|
ui_data_float->default_array_len = 0;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
BLI_assert_unreachable();
|
2024-07-31 18:47:53 +02:00
|
|
|
/* Do not attempt to read unknown data. */
|
|
|
|
|
prop->ui_data = nullptr;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-04-24 17:01:22 +02:00
|
|
|
|
|
|
|
|
if (prop->ui_data) {
|
|
|
|
|
BLO_read_string(reader, &prop->ui_data->description);
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
|
2020-08-21 12:45:33 +02:00
|
|
|
static void IDP_DirectLinkIDPArray(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
|
|
|
|
/* since we didn't save the extra buffer, set totallen to len */
|
|
|
|
|
prop->totallen = prop->len;
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct_array(reader, IDProperty, size_t(prop->len), &prop->data.pointer);
|
2020-08-21 12:45:33 +02:00
|
|
|
|
2021-01-25 23:47:56 -06:00
|
|
|
IDProperty *array = (IDProperty *)prop->data.pointer;
|
2020-08-21 12:45:33 +02:00
|
|
|
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE:, idp-arrays didn't exist in 2.4x, so the pointer will be cleared
|
2020-08-21 12:45:33 +02:00
|
|
|
* there's not really anything we can do to correct this, at least don't crash */
|
2023-07-17 10:46:26 +02:00
|
|
|
if (array == nullptr) {
|
2020-08-21 12:45:33 +02:00
|
|
|
prop->len = 0;
|
|
|
|
|
prop->totallen = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-09 16:35:20 +02:00
|
|
|
for (int i = 0; i < prop->len; i++) {
|
2020-08-21 12:45:33 +02:00
|
|
|
IDP_DirectLinkProperty(&array[i], reader);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_DirectLinkArray(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
|
|
|
|
/* since we didn't save the extra buffer, set totallen to len */
|
|
|
|
|
prop->totallen = prop->len;
|
|
|
|
|
|
2024-07-31 18:39:45 +02:00
|
|
|
switch (eIDPropertyType(prop->subtype)) {
|
|
|
|
|
case IDP_GROUP: {
|
|
|
|
|
BLO_read_pointer_array(reader, prop->len, &prop->data.pointer);
|
|
|
|
|
IDProperty **array = static_cast<IDProperty **>(prop->data.pointer);
|
|
|
|
|
for (int i = 0; i < prop->len; i++) {
|
|
|
|
|
IDP_DirectLinkProperty(array[i], reader);
|
|
|
|
|
}
|
|
|
|
|
break;
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
2024-07-31 18:39:45 +02:00
|
|
|
case IDP_DOUBLE:
|
|
|
|
|
BLO_read_double_array(reader, prop->len, (double **)&prop->data.pointer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
BLO_read_int32_array(reader, prop->len, (int **)&prop->data.pointer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_FLOAT:
|
|
|
|
|
BLO_read_float_array(reader, prop->len, (float **)&prop->data.pointer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_BOOLEAN:
|
|
|
|
|
BLO_read_int8_array(reader, prop->len, (int8_t **)&prop->data.pointer);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
case IDP_ID:
|
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
break;
|
2023-01-13 12:31:27 -06:00
|
|
|
}
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_DirectLinkString(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
2021-06-26 21:35:18 +10:00
|
|
|
/* Since we didn't save the extra string buffer, set totallen to len. */
|
2020-08-21 12:45:33 +02:00
|
|
|
prop->totallen = prop->len;
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_char_array(reader, prop->len, reinterpret_cast<char **>(&prop->data.pointer));
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_DirectLinkGroup(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
|
|
|
|
ListBase *lb = &prop->data.group;
|
|
|
|
|
|
2024-04-24 17:01:22 +02:00
|
|
|
BLO_read_struct_list(reader, IDProperty, lb);
|
2020-08-21 12:45:33 +02:00
|
|
|
|
2021-06-26 21:35:18 +10:00
|
|
|
/* Link child id properties now. */
|
2021-01-25 23:47:56 -06:00
|
|
|
LISTBASE_FOREACH (IDProperty *, loop, &prop->data.group) {
|
2020-08-21 12:45:33 +02:00
|
|
|
IDP_DirectLinkProperty(loop, reader);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void IDP_DirectLinkProperty(IDProperty *prop, BlendDataReader *reader)
|
|
|
|
|
{
|
|
|
|
|
switch (prop->type) {
|
|
|
|
|
case IDP_GROUP:
|
|
|
|
|
IDP_DirectLinkGroup(prop, reader);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_STRING:
|
|
|
|
|
IDP_DirectLinkString(prop, reader);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_ARRAY:
|
|
|
|
|
IDP_DirectLinkArray(prop, reader);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_IDPARRAY:
|
|
|
|
|
IDP_DirectLinkIDPArray(prop, reader);
|
|
|
|
|
break;
|
|
|
|
|
case IDP_DOUBLE:
|
|
|
|
|
/* Workaround for doubles.
|
2020-08-22 00:09:17 +10:00
|
|
|
* They are stored in the same field as `int val, val2` in the #IDPropertyData struct,
|
2020-08-21 12:45:33 +02:00
|
|
|
* they have to deal with endianness specifically.
|
|
|
|
|
*
|
|
|
|
|
* In theory, val and val2 would've already been swapped
|
2020-08-22 00:09:17 +10:00
|
|
|
* if switch_endian is true, so we have to first un-swap
|
2020-08-21 12:45:33 +02:00
|
|
|
* them then re-swap them as a single 64-bit entity. */
|
|
|
|
|
if (BLO_read_requires_endian_switch(reader)) {
|
|
|
|
|
BLI_endian_switch_int32(&prop->data.val);
|
|
|
|
|
BLI_endian_switch_int32(&prop->data.val2);
|
|
|
|
|
BLI_endian_switch_int64((int64_t *)&prop->data.val);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case IDP_INT:
|
|
|
|
|
case IDP_FLOAT:
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_BOOLEAN:
|
2020-08-21 12:45:33 +02:00
|
|
|
case IDP_ID:
|
|
|
|
|
break; /* Nothing special to do here. */
|
|
|
|
|
default:
|
|
|
|
|
/* Unknown IDP type, nuke it (we cannot handle unknown types everywhere in code,
|
|
|
|
|
* IDP are way too polymorphic to do it safely. */
|
|
|
|
|
printf(
|
|
|
|
|
"%s: found unknown IDProperty type %d, reset to Integer one !\n", __func__, prop->type);
|
2021-07-03 23:08:40 +10:00
|
|
|
/* NOTE: we do not attempt to free unknown prop, we have no way to know how to do that! */
|
2020-08-21 12:45:33 +02:00
|
|
|
prop->type = IDP_INT;
|
|
|
|
|
prop->subtype = 0;
|
|
|
|
|
IDP_Int(prop) = 0;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
2023-07-17 10:46:26 +02:00
|
|
|
if (prop->ui_data != nullptr) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
read_ui_data(prop, reader);
|
|
|
|
|
}
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
|
2020-08-28 13:18:24 +02:00
|
|
|
void IDP_BlendReadData_impl(BlendDataReader *reader, IDProperty **prop, const char *caller_func_id)
|
2020-08-21 12:45:33 +02:00
|
|
|
{
|
|
|
|
|
if (*prop) {
|
|
|
|
|
if ((*prop)->type == IDP_GROUP) {
|
|
|
|
|
IDP_DirectLinkGroup(*prop, reader);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* corrupt file! */
|
|
|
|
|
printf("%s: found non group data, freeing type %d!\n", caller_func_id, (*prop)->type);
|
|
|
|
|
/* don't risk id, data's likely corrupt. */
|
|
|
|
|
// IDP_FreePropertyContent(*prop);
|
2023-07-17 10:46:26 +02:00
|
|
|
*prop = nullptr;
|
2020-08-21 12:45:33 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
eIDPropertyUIDataType IDP_ui_data_type(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
if (prop->type == IDP_STRING) {
|
|
|
|
|
return IDP_UI_DATA_TYPE_STRING;
|
|
|
|
|
}
|
|
|
|
|
if (prop->type == IDP_ID) {
|
|
|
|
|
return IDP_UI_DATA_TYPE_ID;
|
|
|
|
|
}
|
|
|
|
|
if (prop->type == IDP_INT || (prop->type == IDP_ARRAY && prop->subtype == IDP_INT)) {
|
|
|
|
|
return IDP_UI_DATA_TYPE_INT;
|
|
|
|
|
}
|
|
|
|
|
if (ELEM(prop->type, IDP_FLOAT, IDP_DOUBLE) ||
|
|
|
|
|
(prop->type == IDP_ARRAY && ELEM(prop->subtype, IDP_FLOAT, IDP_DOUBLE)))
|
|
|
|
|
{
|
|
|
|
|
return IDP_UI_DATA_TYPE_FLOAT;
|
|
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
if (prop->type == IDP_BOOLEAN || (prop->type == IDP_ARRAY && prop->subtype == IDP_BOOLEAN)) {
|
|
|
|
|
return IDP_UI_DATA_TYPE_BOOLEAN;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
return IDP_UI_DATA_TYPE_UNSUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool IDP_ui_data_supported(const IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
return IDP_ui_data_type(prop) != IDP_UI_DATA_TYPE_UNSUPPORTED;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
static IDPropertyUIData *ui_data_alloc(const eIDPropertyUIDataType type)
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
{
|
2024-03-12 15:49:20 +01:00
|
|
|
switch (type) {
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
2025-03-20 11:25:19 +01:00
|
|
|
IDPropertyUIDataString *ui_data = MEM_callocN<IDPropertyUIDataString>(__func__);
|
|
|
|
|
return &ui_data->base;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
2025-03-20 11:25:19 +01:00
|
|
|
IDPropertyUIDataID *ui_data = MEM_callocN<IDPropertyUIDataID>(__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
return &ui_data->base;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
2025-03-20 11:25:19 +01:00
|
|
|
IDPropertyUIDataInt *ui_data = MEM_callocN<IDPropertyUIDataInt>(__func__);
|
2021-08-27 14:31:19 -05:00
|
|
|
ui_data->min = INT_MIN;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
ui_data->max = INT_MAX;
|
2021-08-27 14:31:19 -05:00
|
|
|
ui_data->soft_min = INT_MIN;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
ui_data->soft_max = INT_MAX;
|
|
|
|
|
ui_data->step = 1;
|
2024-03-12 15:49:20 +01:00
|
|
|
return &ui_data->base;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
2023-01-13 12:31:27 -06:00
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
2025-03-20 11:25:19 +01:00
|
|
|
IDPropertyUIDataBool *ui_data = MEM_callocN<IDPropertyUIDataBool>(__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
return &ui_data->base;
|
2023-01-13 12:31:27 -06:00
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
2025-03-20 11:25:19 +01:00
|
|
|
IDPropertyUIDataFloat *ui_data = MEM_callocN<IDPropertyUIDataFloat>(__func__);
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
ui_data->min = -FLT_MAX;
|
|
|
|
|
ui_data->max = FLT_MAX;
|
|
|
|
|
ui_data->soft_min = -FLT_MAX;
|
|
|
|
|
ui_data->soft_max = FLT_MAX;
|
|
|
|
|
ui_data->step = 1.0f;
|
|
|
|
|
ui_data->precision = 3;
|
2024-03-12 15:49:20 +01:00
|
|
|
return &ui_data->base;
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED: {
|
|
|
|
|
/* UI data not supported for remaining types, this shouldn't be called in those cases. */
|
|
|
|
|
BLI_assert_unreachable();
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-03-12 15:49:20 +01:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
IDPropertyUIData *IDP_ui_data_ensure(IDProperty *prop)
|
|
|
|
|
{
|
|
|
|
|
if (prop->ui_data != nullptr) {
|
|
|
|
|
return prop->ui_data;
|
|
|
|
|
}
|
|
|
|
|
prop->ui_data = ui_data_alloc(IDP_ui_data_type(prop));
|
Refactor IDProperty UI data storage
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
2021-08-27 08:27:24 -05:00
|
|
|
return prop->ui_data;
|
|
|
|
|
}
|
|
|
|
|
|
2024-03-12 15:49:20 +01:00
|
|
|
static IDPropertyUIData *convert_base_ui_data(IDPropertyUIData *src,
|
|
|
|
|
const eIDPropertyUIDataType dst_type)
|
|
|
|
|
{
|
|
|
|
|
IDPropertyUIData *dst = ui_data_alloc(dst_type);
|
|
|
|
|
*dst = *src;
|
|
|
|
|
src->description = nullptr;
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
IDPropertyUIData *IDP_TryConvertUIData(IDPropertyUIData *src,
|
|
|
|
|
const eIDPropertyUIDataType src_type,
|
|
|
|
|
const eIDPropertyUIDataType dst_type)
|
|
|
|
|
{
|
|
|
|
|
switch (src_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
switch (dst_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING:
|
|
|
|
|
return src;
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT:
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN:
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT:
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
IDPropertyUIData *dst = convert_base_ui_data(src, dst_type);
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID: {
|
|
|
|
|
switch (dst_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID:
|
|
|
|
|
return src;
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING:
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT:
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN:
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
IDPropertyUIData *dst = convert_base_ui_data(src, dst_type);
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
IDPropertyUIDataInt *src_int = reinterpret_cast<IDPropertyUIDataInt *>(src);
|
|
|
|
|
switch (dst_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT:
|
|
|
|
|
return src;
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID:
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
IDPropertyUIData *dst = convert_base_ui_data(src, dst_type);
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
IDPropertyUIDataBool *dst = reinterpret_cast<IDPropertyUIDataBool *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->default_value = src_int->default_value != 0;
|
|
|
|
|
if (src_int->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<int8_t>(size_t(src_int->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_int->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = src_int->default_array[i] != 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
IDPropertyUIDataFloat *dst = reinterpret_cast<IDPropertyUIDataFloat *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->min = double(src_int->min);
|
|
|
|
|
dst->max = double(src_int->max);
|
|
|
|
|
dst->soft_min = double(src_int->soft_min);
|
|
|
|
|
dst->soft_max = double(src_int->soft_max);
|
|
|
|
|
dst->step = float(src_int->step);
|
|
|
|
|
dst->default_value = double(src_int->default_value);
|
|
|
|
|
if (src_int->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<double>(size_t(src_int->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_int->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = double(src_int->default_array[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
IDPropertyUIDataBool *src_bool = reinterpret_cast<IDPropertyUIDataBool *>(src);
|
|
|
|
|
switch (dst_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN:
|
|
|
|
|
return src;
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID:
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING: {
|
|
|
|
|
IDPropertyUIData *dst = convert_base_ui_data(src, dst_type);
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
IDPropertyUIDataInt *dst = reinterpret_cast<IDPropertyUIDataInt *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->min = 0;
|
|
|
|
|
dst->max = 1;
|
|
|
|
|
dst->soft_min = 0;
|
|
|
|
|
dst->soft_max = 1;
|
|
|
|
|
dst->step = 1;
|
|
|
|
|
dst->default_value = int(src_bool->default_value);
|
|
|
|
|
if (src_bool->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<int>(size_t(src_bool->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_bool->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = int(src_bool->default_array[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
IDPropertyUIDataFloat *dst = reinterpret_cast<IDPropertyUIDataFloat *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->min = 0.0;
|
|
|
|
|
dst->max = 1.0;
|
|
|
|
|
dst->soft_min = 0.0;
|
|
|
|
|
dst->soft_max = 1.0;
|
|
|
|
|
dst->step = 1.0;
|
|
|
|
|
if (src_bool->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<double>(size_t(src_bool->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_bool->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = src_bool->default_array[i] == 0 ? 0.0 : 1.0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT: {
|
|
|
|
|
IDPropertyUIDataFloat *src_float = reinterpret_cast<IDPropertyUIDataFloat *>(src);
|
|
|
|
|
switch (dst_type) {
|
|
|
|
|
case IDP_UI_DATA_TYPE_FLOAT:
|
|
|
|
|
return src;
|
|
|
|
|
case IDP_UI_DATA_TYPE_ID:
|
|
|
|
|
case IDP_UI_DATA_TYPE_STRING:
|
|
|
|
|
return convert_base_ui_data(src, dst_type);
|
|
|
|
|
case IDP_UI_DATA_TYPE_INT: {
|
|
|
|
|
auto clamp_double_to_int = [](const double value) {
|
|
|
|
|
return int(std::clamp<double>(value, INT_MIN, INT_MAX));
|
|
|
|
|
};
|
|
|
|
|
IDPropertyUIDataInt *dst = reinterpret_cast<IDPropertyUIDataInt *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->min = clamp_double_to_int(src_float->min);
|
|
|
|
|
dst->max = clamp_double_to_int(src_float->max);
|
|
|
|
|
dst->soft_min = clamp_double_to_int(src_float->soft_min);
|
|
|
|
|
dst->soft_max = clamp_double_to_int(src_float->soft_max);
|
|
|
|
|
dst->step = clamp_double_to_int(src_float->step);
|
|
|
|
|
dst->default_value = clamp_double_to_int(src_float->default_value);
|
|
|
|
|
if (src_float->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<int>(size_t(src_float->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_float->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = clamp_double_to_int(src_float->default_array[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_BOOLEAN: {
|
|
|
|
|
IDPropertyUIDataBool *dst = reinterpret_cast<IDPropertyUIDataBool *>(
|
|
|
|
|
convert_base_ui_data(src, dst_type));
|
|
|
|
|
dst->default_value = src_float->default_value > 0.0f;
|
|
|
|
|
if (src_float->default_array) {
|
2025-03-20 11:25:19 +01:00
|
|
|
dst->default_array = MEM_malloc_arrayN<int8_t>(size_t(src_float->default_array_len),
|
|
|
|
|
__func__);
|
2024-03-12 15:49:20 +01:00
|
|
|
for (int i = 0; i < src_float->default_array_len; i++) {
|
|
|
|
|
dst->default_array[i] = src_float->default_array[i] > 0.0f;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return &dst->base;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IDP_UI_DATA_TYPE_UNSUPPORTED:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
ui_data_free(src, src_type);
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-30 11:27:03 +00:00
|
|
|
/** \} */
|