| Age | Commit message (Collapse) | Author |
|---|
|
|
|
E.g. typing `bpy.data.bl_rna.properties[8].<tab>` in console would hard-crash
trying to dereference NULL pointer. Was a missing check in rna_Property_tags_itemf().
|
|
We have to check all items of a collection when we want to create
overrides as needed...
|
|
When a name property is defined for collection's struct, but no name is
actually set, we want to also fallback to index case. We cannot handle
empty names to address items of a collection!
|
|
|
|
|
|
E.g. running `bpy.context.active_object.cycles.bl_rna.property` in the
console would crash.
Thanks @lijenstina for reporting!
|
|
Code also handling auto-generation of static overrides.
Aside from some naming consistency cleanup, this commit:
* Is the first step addressing the 'operator' issue with static
overrides, by implementing a first version of the 'restore from
reference' behavior.
* Fixes several issues that were discovered on the way in enhanced
RNA comparision code, like the 'zero-length dynamic array' case, or some
infinite looping caused by some non-ID pointers (that for some
mysterious reasons did not show up previously...).
* Factorizes a bit said RNA comparison code (auto-static override
generation and comparison/check were essentially doing the same thing).
|
|
|
|
|
|
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
|
|
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
|
|
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
Actual usage of this will be added in a follow-up commit.
|
|
Practically all access to enum data is read-only.
|
|
Required to generate valid doc for such arrays!
|
|
Only add subclasses of: Menu, Panel, Header, UIList, Operator
This helps avoid unnecessary naming collisions,
See T52599 for details
|
|
Adding structs was checking for duplicates
causing approx 75k string comparisons on startup.
While overall speedup is minimal,
Python access to `bpy.types` will now use a hash lookup
instead of a full linked list search.
See D2774
|
|
internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
|
|
Needed since dynamic arrays would have zero length.
|
|
Some dynamic enums, which do not need a valid context pointer, have their 'itemf'
callback always called. This is annoying for introspection tools (like the ones generating
translations, or API documentation), because it means they never have access to all possible
options (enum items).
So now, there is also an `enum_items_static` accessor to get only statically-defined
enum items.
Note: only i18n tools take advantage of this currently, others are still to be updated.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D1782
|
|
boolean return.
Since rBbbc7dc169dc365889bad3f3aed7b868efb432710 bool-valued RNA functions are expected to
return only 0 or 1. For flag tests as in these functions the returned int value needs to be
explicitly converted to bool.
|
|
Definitions could shadow local vars.
|
|
|
|
Was returning NULL, auto-completing:
bpy.types.Material.bl_rna.properties["type"].
Would crash, accessing 'default_flag', thanks to @lukastoenne for investigating.
|
|
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
|
|
This mostly helps making Cycles scene synchronization a bit faster.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in API doc generation.
Thanks Campbell for the much better name suggestion!
|
|
Issue is that the real default context is NULL, however, in python and RNA, this value can't be used easily. So we use a specific string instead ("*"), defined as BLF_I18NCONTEXT_DEFAULT_BPYRNA.
From now on, all bpy/rna code should only use the BLF_I18NCONTEXT_DEFAULT_BPYRNA value, while all "usual" C code should use the BLF_I18NCONTEXT_DEFAULT value (BLF_pgettext is still able to "understand" both, anyway).
Also added BLF_is_default_context helper func, so that we can keep that check in a single place!
Finally, we should no need anymore to understand the void string "" as default context too - two values for a same thing are more than enough!
|
|
they do.
I've added a separate camera unit type. It's a bit strange to have an exception for
this but it ensures units are shown in familiar millimeters and it also ensures
backwards compatibility.
|
|
|
|
returns true for actually optional functions.
|
|
suggestions!
This commit adds:
* A new bpy.app.translations module giving some info about locales/translation stuff (current active locale, all locales currently known by blender, all translation contexts currently defined, etc.).
* The ability for addons to feature translations, using the (un)register functions of above module.
* Also cleans up "translate py string when storing into RNA prop" by removing "PROP_TRANSLATE" string's subtype, and adding a PROP_STRING_PY_TRANSLATE flag instead (this way it is no more exposed to python...).
Addon translations work with py dictionaries: each addon features a dict {lang: {(context, message): translation, ...}, ...}, which is registered when the addon is enabled (and unregistered when disabled).
Then, when a key (context, message) is not found in regular mo catalog, a cache dict for current locale is built from all registered addon translations, and key is searched in it.
Note: currently addons writers have to do all the work by hand, will add something (probably extend "edit translation" addon) to automate messages extraction from addons soon(ish)! To get a look to expected behavior from addons, have a look at render_copy_settings/__init__.py and render_copy_settings/translations.py (rather stupid example currently, but...). Once we have a complete process, I'll also update relevant wiki pages.
|
|
icon when available.
|
|
add Ctrl+Shift+Tab shortcut for selecting snap type to the UV editor too.
also added icon drawing to WM_OT_context_menu_enum() so it gets the icons from the enum to draw them in the menu.
|
|
with FUNC_NO_SELF were treated as static methods, which is not sufficient for getting actual type information if the function can not be generated in advance in makesrna. Now the FUNC_USE_SELF_TYPE flag can be set in addition to FUNC_NO_SELF (if FUNC_NO_SELF is not set, FUNC_USE_SELF_TYPE has no effect). Such functions will be interpreted as class methods and must take a StructRNA pointer argument. This pointer is the same as the type member in PointerRNA, but can be passed without an actual data/id instance.
|
|
|
|
|
|
|
|
Rationale: custom props on linked objects are editable through ops and the console but the UI code calls RNA_property_editable() which returns false if (id->lib && !(prop->flag & PROP_LIB_EXCEPTION))
Setting the 'LIBRARY_EDITABLE' flag allows UI templates to change these props (but the changes aren't saved!) for things like indices into CollectionProperties which live on the linked object
|
|
|
|
Note about long lines: I did not touch to two pieces of code (because I don’t see any way to keep a nicely formated, compact code, with shorter lines):
* The node types definitions into rna_nodetree_types.h
* The vgroup name functions into rna_particle.c
|
|
|
