When path to resolve "finishes" on a collection prop, do not erase the returned prop!
This caused py's path_resolve to return same PointerRNA as the one passed as parameter, leading to
inifinte recursion in Operator's accessor func (__getattribute__)...
The copy-to-selected operator for RNA buttons uses paths for copying
object pointer properties. Copying other ID data blocks is deliberately
disabled:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_ops.c$274
However, the RNA_path_resolve_full function is not properly working for
retrieving pointer properties: it always will dereference pointer
properties in anticipation of further path elements.
In fact the return value of RNA_path_resolve_full has a conflicting
double meaning. It returns `false` when
* the RNA path is invalid
* any of the pointer properties is NULL
This means that it is not capable of returning pointer properties at all.
To make this possible, there is now an internal function for path
parsing, which returns false //only// if the the path is invalid.
On top of this there are 4 wrapper functions for retrieving either
actual property values (RNA_path_resolve, RNA_path_resolve_full) and for
retrieving pointer+property pairs (RNA_path_resolve_property,
RNA_path_resolve_property_full). The latter 2 variants will **not**
dereference pointer properties at the end of the path, so callers can
actually get the property itself. The `***_full` variants include an
array index return value.
Differential Revision: https://developer.blender.org/D396
* Moved collection key parsing and array index parsing into their own
functions, to make the main path loop easier to follow.
* Unified boolean return values.
single terminator item.
Ideally no enum item function should return NULL, but since this is very
common and an intuitive mistake, better handle that case gracefully in
the RNA access function.
When setting keymap properties to values equalling the RNA default, they will
get "unset" and automatic operator behavior is used. There is no way to
explicitly set the default value as a user.
1) To allow distinguishing uninitialized (not set) properties in the keymap
items, a few changes to the RNA struct comparison function are needed: Instead
of allowing only strict/non-strict comparison of 2 properties A and B in a
struct, this now has 3 modes:
* STRICT: compare only the actual property values (same as 'strict' before)
* UNSET_MATCH_ANY: if either A or B is unset, consider them a match (same as
non-strict before)
* UNSET_MATCH_NONE: if one property is set and the other not, consider them a
mismatch.
The new UNSET_MATCH_NONE mode is useful for keymaps, because it allows keeping
user-defined property values in the keymap even if they match the default
property value (see wm_keymap_diff function in wm_keymap.c)
2) A new operator is added for unsetting ID properties in the RMB context menu
and in user preferences next to keymap properties. This only works on ID
properties and deletes the ID property storage, so that the default value is used.
In the user preferences for keymaps the properties are shown in an inactive
layout to indicate that the default value is used (which some operators such as
the "select linked" op from the report use to trigger automatic behavior). When
the user sets a property it gets set and stays that way until explicitly "unset"
using the new operator.
When printing operator reports, ommit unset properties.
This is needed because in some cases operators check if a value is set or not, so filling in default arguments may change behavior.
* It was not clear that RNA_parameter_length_get() & co only affected dynamic properties, renamed them to RNA_parameter_dynamic_length_get() and such.
* Fixed RNA_function_find_parameter(), we can't use BLI_findstring() here, need to call RNA_property_identifier()!
* Fixed RNA_parameter_get() and RNA_parameter_set(), which were completely wrong for dynamic properties.
* Fixed RNA_parameter_dynamic_length_get/set_data(), they did not check the property was actually a dynamic one and were using again ugly blackmagic casting intead of ParameterDynAlloc structure!
* makesrna was still using an ugly hackish (and perhaps not always working) code when handling dynamic parameters, now synchronized with RNA_parameter_dynamic_length_get_data and RNA_parameter_get code.
down, this time by the operator properties getting converted to a string for
display in the info window.
With 1000+ stroke points this can get slow, and takes up too much space anyway,
so now it's (somewhat arbitrarily) limited to printing only 10 points.
Some enums' items actually are generated from data (like the render layers of compo nodes), so they should not be translated. Added a PROP_ENUM_NO_TRANSLATE new RNA flag to tag those enums (only found those for nodes, but may be more of them around).
Also fix similar issue in main list of render layers (Py UI code! :P ).
