This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/animation` module.
No functional changes.
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
Cheap tip: anything that is not "Camel Case" and/or that is more than
a few words long should use `TIP_` translation, not `IFACE_` one.
Also added several missing strings (including the one reported in D5056
by Jean First (@robbott), thanks).
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
Thanks Sergey for the patch!
This bug, and many like it would arise because at some point a F-Curve would get
detected as being unable to be resolved (when trying to display its name in an
Animation Editor), so gets tagged as being "disabled". It was assumed that such
channels usually belonged to deleted data or stuff that wouldn't be able to be
resolved again for a long time. However, in cases like UV settings, they may
only be unavailable temporarily.
As a compromise, this patch clears this disabled flag if a channel is found to
be now working when (in the process of finding out its name when redrawing an
Animation Editor) it can be resolved, in the same place where the disabling was
taking place. This doesn't work fullproof in tests I've done, but should be
nicer than before.
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
* F-Curves no longer show the name of the datablock of the property
they affect if this is an ID-block. For example, transform curves for
a cube won't get the "... (Cube)" suffix anymore. In these cases, it's
relatively clear that these belong to the parent datablock, so doing
this should be fine (and reduces clutter).
However, for non-id data (i.e. subsurf modifier settings) or bones,
this info still gets shown. In these cases, there is some ambiguity.
* "ActiveAct: <...>" is no longer shown for NLA action channels (i.e.
just the name of the action gets shown). This should make it easier to
see at a glance what action is being used.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
Buttons for editing RNA paths/array index for F-Curves that aren't working are now actually functional. This means that when invalid paths are present, they can be manually fixed up.
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
