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.
- yes, this does break scripts, but the api is marked experimental.
ED_region_draw_cb_activate() adds a callback to a region type whereas the api made it look like the callback was being added to the region instance.
Use a class method on bpy.types.Space to manage region drawing, eg.
was:
self._handle = context.region.callback_add(draw_callback_px, args, 'POST_PIXEL')
is now:
self._handle = bpy.types.SpaceView3D.draw_handler_add(draw_callback_px, args, 'WINDOW', 'POST_PIXEL')
- PyLong_FromSsize_t --> PyLong_FromLong
- PyLong_AsSsize_t --> PyLong_AsLong
In all places except for those where python api expects PySsize_t (index lookups mainly).
- use PyBool_FromLong in a few areas of the BGE.
- fix incorrect assumption in the BGE that PySequence_Check() means PySequence_Fast_ functions can be used.
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.
When this new subtypes is used, then string of property is hidden using
asterisks, e.g.: mysecretpassword -> ****************
This code was reviewed and modified by Brecht. Thanks very much:
- https://codereview.appspot.com/6713044/
This new subtype of string property is intended mostly for Add-on developers
writing Add-on which communicates with some server (http, sql, ftp, verse,
etc.). When this server requires user authentication and user has to type
username and password, then current API didn't allow to type 'hidden' password,
e.g. when you want to demonstrate this script, then everybody can see this
security password. Some examples of Add-on which could use this new subtype:
- On-line database of textures
- Integration of render farm
- Integration of Verse
Security Notes:
- You can copy paste hiddent string of property from text input using (Ctrl-C, Ctrl-V),
but you can do this in other GUI toolkits too (this behavior it is widely used).
- Text of string property is stored in plain text, but it is widely used in other
GUI toolkits (Qt, Gtk, etc.).
Simple examples:
- https://dl.dropbox.com/u/369894/draw_op_passwd.py
- https://dl.dropbox.com/u/369894/blender-password.png
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.
this breaks and causes bug: [#32720], where sys.stdout becomes invalid and print() does nothing.
On investigation - python is not getting the environment variable from blender (aparently because its a DLL?) so this should be resolved rather then overwriting sys.stdout.
nice obscure case, when a script executes, frees its self (by loading a file for eg), then has a python error.
... in this case blender would fetch the python exception and attempt to move the cursor in the freed textblock to the error line, crashing blender.
