- 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
* When there is only a single keyframe for a F-Curve, the handles aren't shown anymore. This looks nicer than the fat orange blobs that appeared
* Tweaked the management of GL_BLEND when drawing animation channels in the Graph Editor in an attempt to fix some of the missing text drawn issues.
* Converted the properties panel to use layout engine + added color selectors
* Only F-Curves and Drivers that affect selected bones will be visible when this happens.
* Moved the function to grab text within a pair of "" following some prefix to blenlib.
In Animation Editors, F-Curves for Pose Channel Constraints now include the Pose Channel and Constraint names in the 'owner' part of the name displayed, making it easier to identify which Pose Channel some constraint F-Curve belonged to.
e.g. The influence setting for an IK Constraint on bone "Boney"
Old Version: Influence (IK)
New Version: Influence (Boney : IK)
We can experiment with different representations of this later (maybe '>' instead of ':' ?)
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
The 'Show Sliders' option for DopeSheet and Graph Editors now works again. When this option is enabled (it is disabled by default), a slider (or combobox) is shown beside the mute/lock toggles for F-Curves. Editing the slider will result in a new keyframe being added on the current frame.
So, for all the (ex)-Maya animators out there, you can now animate in a channelbox-like way. :)
Also in this commit:
* Fixed some warnings in modifier.c from previous commits there
* Fixed some refresh problems with DopeSheet channel list (which were only obvious after adding back the sliders)
* Removed the old/unrestored and nasty slider code used in the past by the Action Editor only.
* Reviewed subtypes, making them more specific and adding new ones.
* Subtypes now have an associated type of units (length, area, volume,
mass, rotation, time, velocity, acceleration). These are not used
yet anywhere.
* Centralized code that decides the name of array items based on
subtype (XYZ, RGB), was copied in 3 places.
* RNA_def_float etc functions still need to be update, will do this
later together with another change.
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD
Notes:
* Game and sequencer RNA, and sequencer header are now out of date
a bit after changes in trunk.
* I didn't know how to port these bugfixes, most likely they are
not needed anymore.
* Fix "duplicate strip" always increase the user count for ipo.
* IPO pinning on sequencer strips was lost during Undo.
* Trying a slightly different approach with curve drawing. Now curves aren't drawn darker down the list, as that approach proved to have massive contrast issues all around. However, it's not completely back to the old rainbow style, as the colours are still grouped in 3's and 4's, only that they now use hue offsets...
* Unselected curves are now drawn less opaque. However, selected curves still leave some brightness to be desired...
* Bugfix - Deselecting keyframes in graph view now deselects the curves too.
This new algorithm groups F-Curves into groups of 3-4 with similar colours, since triplets of related settings are more likely to be encountered.
The colours get darker down the list. Blocks of related F-Curves will alternate between being boldly and weakly shaded.
I've left the old method still there but commented out. This new method could still be improved, as some of the colours chosen don't really stand out that well IMO.
Testing and suggestions welcome as always :)
The Python API to define Panels and Operators is based on subclassing,
this makes that system more generic, and based on RNA. Hopefully that
will make it easy to make various parts of Blender more extensible.
* The system simply uses RNA properties and functions and marks them
with REGISTER to make them part of the type registration process.
Additionally, the struct must provide a register/unregister callback
to create/free the PanelType or similar.
* From the python side there were some small changes, mainly that
registration now goes trough bpy.types.register instead of
bpy.ui.addPanel.
* Only Panels have been wrapped this way now. Check rna_ui.c to see
how this code works. There's still some rough edges and possibilities
to make it cleaner, though it works without any manual python code.
* Started some docs here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATypeRegistration
* Also changed some RNA_property and RNA_struct functions to not
require a PointerRNA anymore, where they were not required (which
is actually the cause of most changed files).
In this commit, I've experimented with the way in which F-Curve names (seen in DopeSheet/Graph Editor) are put together.
Now, F-Curve names are assembled in the form:
<array-index> <property-name> (<struct-name>)
i.e. "X Location (Bone)", "Y Location (Object)"
"Specularity (VeryLongMaterialName)", etc.
The goal of this experiment was to hopefully make it quicker to do a left-margin scan and identify the defining differences between closely related F-Curves.
- This has the benefit of no (potential) need for horizontal scrolling back and forth to see and compare the end portions of names, and also to avoid the important parts of the name getting pushed out of the standard viewable area by some owner-struct long names.
- The downside is the loss of the clear hierarchial layout closely related to the RNA-paths used internally, that was provided by the old method. Also, this method also looks rather awkward on first glance, but if it improves efficiency of use, why not :)
