| Age | Commit message (Collapse) | Author |
|---|
|
Initially there was hope at least part of this work could be used for
dynamic overrides as well... but looks like not, so better be specific
and avoid any confusion.
PS: this commit break any file saved with static overrides, should not
be an issue though.
|
|
|
|
|
|
|
|
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.
|
|
local and reference are awfully confusing names here, since destination
is a copy of reference that will become local override once applied, and
source is .blend-file-written version of local override...
|
|
Main reason here is to make comparison/override_diff/override_store/override_apply
customizable per RNA property if needed.
This should allow us especially to get advanced behavior on case-by-case
basis, when dealing with Pointer and Collection properties mostly.
Note that IDProps remain fuzzy area for now, a big part of the code
tries to take them into account, but it's most likely still missing some
bits, and definitively not tested at all yet!
|
|
|
|
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
|
|
For now chose some teal blue to mark overridden state of prop in UI,
kind of last nicely different tint available...
|
|
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
|
|
|
|
name), and a first default "Operator" one for all operators' label.
The fact is, operators' label are nearly always verbs, while properties labels are nearly always nouns. So this should already solve many translations' problems regarding noun/verb confusion.
This commit also simplifies a bit i18n usage:
*Now IFACE_ and TIP_ macros (or there context versions, CTX_IFACE_/TIP_) are used nearly everywhere (with one exception, where code is a bit complex and needs to manually test whether ui/tip translations is allowed, so no need to redo it later through those macros).
*Also, those macros are now defined to NOP in case WITH_INTERNATIONAL is false, which avoid testing that define everywhere in code!
|
