Also enhanced the ugly py ast parsing code, so that it now can handle (up to some extent) "name" function nodes, and add bpy.app.translations.pgettext func familly to extracted ones...
This ast py parsing becomes more and more ugly, should probably try to refactor it a bit. :/
Also generate rigid body constraint types in py bullet code from RNA enum values (simpler than having to sync the code when something is changed here!).
Side note: RNA API about icons still needs to expose icons for enum values, and conversion funcs between icon_name and icon_value!
For python operators that used the ExportHelper mix-in class, an empty file field would become '.ext', entering and existing the text field would become '.ext.ext',
Now only add an extension if the filename part of the path is set, so '.ext' will still become '.ext.ext' but having only the extension isn't so likely to happen in the first place now.
This is a different fix then the changes suggested in the report but I'd prefer to keep path functions stupid+predictable.
* handle nicely multiple empty lines in po files (still have to figure out why po writer sometime output two lines instead of one!)
* fix rtl processing!
Notes:
* Most tools here have been updated, only a few (unused :p ) features should be missing. But some updates are rough for now, and performances are globally worse currently, will address this later (this is only really noticeable when you work over the whole repo, anyway ;) ).
* This update breaks "edit translations" addon, will fix it later, once core (i.e. this module) is considered stable again!
- bpy.path.extensions_image
- bpy.path.extensions_movie
- bpy.path.extensions_audio
eg:
if os.path.splitext(filename)[1].lower() in bpy.path.extensions_image:
... we have an image ...
- add sequence.update(data=False) function.
- made some sequence vars editable.
- correct some comments.
also rename rna function sequence.getStripElem() --> strip_elem_from_frame()
bake_action tries to make kind of a 'visual keying'... On one side, this is rather stupid when you keep constraints (in this case, keying actual loc/rot/scale transforms, i.e. matrix_basis, is enough, doing more would lead to unexpected behavior with some constraints). On the other one, making a good visual keying of bones is *really* tricky, so now using the new object's convert_space() func to compute that (when the user chooses to remove the constraints).
Incidentally, this greatly simplifies the code of bake_action!
It introduces a new (py-extendable and registrable) RNA type, UIList (roughly similar to Panel one), which currently contains only "standard" list's scroll pos and size (but may be expended to include e.g. some filtering data, etc.). This now makes lists completely independent from Panels!
This UIList has a draw_item callback which allows to customize items' drawing from python, that all addons can now use. Incidentally, this also greatly simplifies the C code of this widget, as we do not code any "special case" here anymore!
To make all this work, other changes were also necessary:
* Now all buttons (uiBut struct) have a 'custom_data' void pointer, used currently to store the uiList struct associated with a given uiLayoutListBox.
* DynamicPaintSurface now exposes a new bool, use_color_preview (readonly), saying whether that surface has some 3D view preview data or not.
* UILayout class has now four new (static) functions, to get the actual icon of any RNA object (important e.g. with materials or textures), and to get an enum item's UI name, description and icon.
* UILayout's label() func now takes an optional 'icon_value' integer parameter, which if not zero will override the 'icon' one (mandatory to use "custom" icons as generated for material/texture/... previews).
Note: not sure whether we should add that one to all UILayout's prop funcs?
Note: will update addons using template list asap.
http://lists.blender.org/pipermail/bf-committers/2012-December/038555.html
Note: NodeTree and Node currently use standard python classes generated by bpy for now. The customnodes branch defines such classes as well, with specialized metaclasses for use with ID properties. Not needed in trunk yet.
Since the window manager is needed for keymaps this is kept as an exception.
some addons will need updating, but in every case I've seen addons should not be accessing the context while registering.
(bad stuff! - declaring the scene as a global variable - which crashes when the users loads a new file, manipulating the active object or scene... tsk tsk)