Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
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!
|
|
Addresses:
* C++ comments.
* Spaces after if/for/while/switch statements.
* Spaces around assignment operators.
|
|
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.
|
|
bpy.types.Modifier.bl_rna.properties["type"].default_flag
now check the default/default_flag match the enum property they are used with.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
- rename define DISABLE_SDL --> WITH_SDL (which was already used in some places)
- blenders interation preset was using orbit rather then turntable 3d view preference (different from factory defaults).
- tagged some unused rna args.
|
|
|
|
|
|
layout.prop("blah", text="Translate Me!")
|
|
This branch adds mostly organizational improvements to the node system by renaming the node folders and files. A couple of internal features have been added too.
Detailed information can be found on the wiki page:
http://wiki.blender.org/index.php/User:Phonybone/Particles2010
|
|
|
|
used by operator presets.
|
|
|
|
needed for dynamic python enums.
|
|
changed by units.
|
|
- use BLI math funcs for normal float/short conversion.
- correct some un-intentional float/double promotions.
|
|
Was a naming collision with 'keys' python method, reserve keys/items/values/get for python.
Updated animsys_update.py for shapekey data paths.
renamed:
Particle.hair --> hair_keys
Particle.keys --> particle_keys
Key.keys --> key_blocks
EnumProperty.items --> enum_items
KeyMap.items --> keymap_items
noted:
http://wiki.blender.org/index.php/Dev:2.5/Py/API/Updates#Since_2.56a
|
|
|
|
|
|
|
|
|
|
defined.
since the property hash is maintained there is no reason for this, especially since the property could be in the StructRNA's parent class.
|
|
MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h.
no functional changes.
|
|
runtime exception.
problem was there was no way to tell the difference between getting an empty item from a collection or the item not being found.
|
|
|
|
|
|
also fix for bug where soft limits could be greater then hard limits with bpy.props.* functions.
|