Summary:
This commit removes ~10000 strlen calls and ~100000 memcpy calls in blender (profiled with blender --background), ~10000 memcpy calls in makesdna.
There is no need to create null-terminated strings for atoi, because it converts only the initial portion of the string anyway.
Also it was noticed that DNA_elem_array_size and arraysize functions work only with full strings, so there is no point to calculate strlen.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: http://developer.blender.org/D105
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!
PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements.
=== Dynamic node type registration ===
Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes.
Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2].
=== Node group improvements ===
Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3].
The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there.
[1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes
[2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender
[3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
there were 2 bugs here.
- int buttons scaling values on input but not on display.
- pixel distances were using PROP_DISTANCE subtype - which isn't correct.
added assert incase PROP_INT values have PROP_DISTANCE subtype applied in future.
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.
The current C callback functions are too simple allow a straightforward implementation, in particular they don't receive the PropertyRNA pointer itself as an argument, which means the callback cannot directly access the PropertyRNA's py_data pointers which store the python function objects. For this reason a second runtime variant of these callbacks has been added. It is only used for runtime callbacks and not in makesrna, but otherwise works the same way.
Removing data then accessing would allow invalid memory access and often crash.
Example:
import bpy
image = bpy.data.images.new(name="a", width=5, height=5)
bpy.data.images.remove(image)
print(image.name)
Now access to the removed data raises an error:
ReferenceError: StructRNA of type Image has been removed
This is the same level of error checking that was done in blender 2.4x but was made difficult by RNA functions not having access to the PyObject's.
Now both UI translation menu (in userprefs) and isocodes are defined in a text file (release/datafiles/locale/languages), parsed at lunchtime. This way:
* No more need to edit Blender code each time we want to add an new language or reorganize the existing menu;
* Translators can easily add a new language for testing, by just editing the text file, so no more need to ask to change Blender code and wait for a new build to see your new translation work in Blender!
Remaining todo:
* Commit i18n py tools
* Update wiki doc!
use the same precision for location all over (2-5 was used), use define as 5.
also disallow boolean to have any subtype besides PROP_LAYER_MEMBER, some booleans had TRANSLATION / XYZ subtypes which don't make sense.
Operator descriptions can be NULL pointers,
fix this by making use of PROP_NEVER_NULL flag, when its not set, generated string funcs will test for NULL.
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
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!
This commit implements a way to define context of property which is used by
localization stuff and which is needed to resolve translation context when
some word wit the same english spelling is used in different meanings
(like Manual in meaning of tutorial, and Manual in meaning of something is
setting up by hand).
To define property's context there's a function RNA_def_property_translation_context.
If property doesn't have context, regular BLF_gettext function is used to get
translation of property name, otherwise BLF_pgettext is used for this.
Hence, for correct translation, messages in .po files should be marked
by "msgctxt" context, otherwise property with context declared wouldn't
be translated at all. Toolchain scripts from bf-translation project
would be updated soon.
If context for some values of enumerator property, property itself should
be moved to other context and all items from this enum would be moved to
this context automatically (it's impossible to move one few items to
another context).
P.S. Think context like "BRUSH" or "MODIFIER" are preferable than "NOUN" and "VERB"
because in some cases the same english noun used in different areas better be
translated differently to make translation more native.
Talked with Brecht and Campbell and they both agreed that bpy.types should match bpy.props
In the ideal world we would rename bpy.props to BooleanProperty. This would break scripts though. So we go for a compromise and at least have some consistency.
