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)
Our current intl build for windows is quite old (don't know the exact version), and does not have the new setlocale overwrite. Problem is, new windows dll have no more the gettext_putenv helper, which is currently mandatory to make it work for this OS.
So back for now to the ugly long_locales for win. Best fix is probably to build our own static version of libl, but this is not trivial and will require some time. :/
PS: I had a look over i18n/translation in wxWidget, Qt and boost: all implement their own system, even though wxWidget and boost use po/mo files...
Made it so meshes, curves, surfaces and metaballs are scaling to a grid cell size,
which makes them behave consistently now.
There're still issues to be resolved still:
- Lattice is not scaled to grid cell size yet, it uses slightly different add
function which makes scaling a bit tricky and hacky. Would prefer to do a
bit bigger refactor here, so it's a TODO for now.
- Cameras, speakers and other helpers are not scaling. They don't have data
on which scale could be applied and perhaps it should be some kind of draw
scale. Also would consider it's a TODO for now.
