Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34732] trunk/blender/release/bin/ blender-thumbnailer.py: patch [#25972] blender-thumbnailer.py: GVFS support
Thanks Campbell. There is another issue I forgot: unlike Blender itself,
an x86 thumb handler won't run on x64 Windows. Can the build systems
handle this?
On 10/02/2011 12:57, Campbell Barton wrote:
@Xavier,
blender-thumbnailer.py is a standalone script and runs without blender
in py2.x - 3.x
its included so tools may extract thumbnails from blender without
loading blender.
blender does this internally in C, from thumbs_blend.c: loadblend_thumb.
@Tom Edwards, there doesn't seem to be a good place for this to go in
blenders source.
For now how about: ./source/tools/windows_thumbnail/ ?
On Wed, Feb 9, 2011 at 9:20 PM, Tom Edwardscont...@steamreview.org wrote:
Thumbs are generated by Blender on save and stored in the file as RGBA
pixels. There is no risk.
On this topic, I keep wanting to submit my Windows thumbnail handler but
I don't know where it should go in the source tree. It has to be a
dynamic lib, but it's not exactly external...any suggestions?
On 09/02/2011 2:34, Xavier Thomas wrote:
Hi Campbell,
I would like to know if the Blender thumbnailer deactivate python scripts
inside the blend.
Thumbnailers are big security issues. A malisous .blend on a USB memory
stick could serve as infection vector on all platform. Executing some of the
py scripts inside would make it too easy.
Xavier
2011/2/9 Campbell Bartonideasma...@gmail.com
Revision: 34732
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34732
Author: campbellbarton
Date: 2011-02-09 02:09:30 + (Wed, 09 Feb 2011)
Log Message:
---
patch [#25972] blender-thumbnailer.py: GVFS support
from Shinsuke Irie (irie) with some minor edits.
Shinsuke's description from the tracker:
---
I have implemented GVFS framework support of blender-thumbnailer.py which
allows some file managers like Nautilus and Thunar to show thumbnails in
trash or network directories. If Python's gio module is available, the
thumbnailer uses it to access to filesystems mounted via GVFS. This change
shouldn't affect desktop environments other than GNOME and XFCE.
A function gvfs_open() in this patch is defined to solve a stupid
incompatibility between Python file object and GIO Seekable object.
On Ubuntu 10.10, I confirmed thumbnails can be generated for file://,
trash://, sftp://, and smb://.
Modified Paths:
--
trunk/blender/release/bin/blender-thumbnailer.py
Modified: trunk/blender/release/bin/blender-thumbnailer.py
===
--- trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:25
UTC (rev 34731)
+++ trunk/blender/release/bin/blender-thumbnailer.py2011-02-09 02:09:30
UTC (rev 34732)
@@ -24,27 +24,49 @@
Thumbnailer runs with python 2.6 and 3.x.
To run automatically with nautilus:
gconftool --type boolean --set
/desktop/gnome/thumbnailers/application@x-blender/enable true
- gconftool --type string --set
/desktop/gnome/thumbnailers/application@x-blender/command
blender-thumbnailer.py %i %o
+ gconftool --type string --set
/desktop/gnome/thumbnailers/application@x-blender/command
blender-thumbnailer.py %u %o
import struct
+def open_wrapper_get():
+ wrap OS spesific read functionality here, fallback to 'open()'
+
+
+def open_gio(path, mode):
+g_file = gio.File(path).read()
+g_file.orig_seek = g_file.seek
+
+def new_seek(offset, whence=0):
+return g_file.orig_seek(offset, [1, 0, 2][whence])
+
+g_file.seek = new_seek
+return g_file
+
+try:
+import gio
+return open_gio
+except ImportError:
+return open
+
+
def blend_extract_thumb(path):
import os
+open_wrapper = open_wrapper_get()
# def MAKE_ID(tag): ord(tag[0])24 | ord(tag[1])16 |
ord(tag[2])8
| ord(tag[3])
REND = 1145980242 # MAKE_ID(b'REND')
TEST = 1414743380 # MAKE_ID(b'TEST')
-blendfile = open(path, 'rb')
+blendfile = open_wrapper(path, 'rb')
head = blendfile.read(12)
if head[0:2] == b'\x1f\x8b': # gzip magic
import gzip
blendfile.close()
-blendfile = gzip.open(path, 'rb')
+blendfile = gzip.GzipFile('', 'rb', 0, open_wrapper(path, 'rb'))
head = blendfile.read(12)
if not head.startswith(b'BLENDER'):
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers
Re: [Bf-committers] Memory bug
Hi,
On Thu, Feb 10, 2011 at 5:40 PM, ra...@info.upr.edu.cu wrote:
float *vert= (float *)MEM_callocN(3*me-totverts*sizeof(float ),
vertsmooth);
eve= em-verts.first;
int counter = 0;
while(eve) {
if(eve-f SELECT) {
(eve-tmp).p = vert[counter];
(eve-tmp).fp = 0.f;
Don't set fp to 0.f, since tmp is a union this also affects p. You can
one of the two, but not both at the same time.
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Memory bug
Hi Bretch :)
Thanks a lot! this certainly explain everything ;)
I need to store several different values, I need a float[3] for
accumulating neighbours positions, an int to store neighbours amount and
more advanced relaxation algorithm may need to store aditional
information like face area, angles , springs and stuff like that so as a
solution I will create a new structure with those fields and use the
(void *)tmp.p to store and retrieve them all.
Cheers
Raul
Hi,
On Thu, Feb 10, 2011 at 5:40 PM, ra...@info.upr.edu.cu wrote:
float *vert= (float *)MEM_callocN(3*me-totverts*sizeof(float ),
vertsmooth);
eve= em-verts.first;
int counter = 0;
while(eve) {
if(eve-f SELECT) {
(eve-tmp).p = vert[counter];
(eve-tmp).fp = 0.f;
Don't set fp to 0.f, since tmp is a union this also affects p. You can
one of the two, but not both at the same time.
Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] RNA Extension Registration
Hi, So, looking at this again, as I understand it, the main decision that needs to be taken is if we want auto registration to be opt-in or opt-out. The only difference would be a few standard lines at the end of scripts. I prefer this to be opt-in personally. Regarding the implementation, that's hard to judge for me, but I guess that in the case we decide on opt-in and that means the implementation can be simplified in places, then it's logical to do so. Brecht. On Thu, Jan 27, 2011 at 9:57 AM, Campbell Barton ideasma...@gmail.com wrote: Hi Martin, Just looked into your patch and while its improved and more flexible improvement its still creating an environment which is overkill IMHO. This goes back to the problem that you want to keep auto-registration and I'm not convinced its better then an api which gives a convenience registration function for script authors to access. This can simply be solved by collecting classes and having a single function to register them, anything more then this increases complexity of our internals significantly and only means we avoid a few lines at the end of the scripts. Updated my patch posted earlier to the ML, with minor changes. - Uses metaclass to collect classes as we agreed. - Includes line of class definition to include on registration errors (like you added with yours). Attached the updated patch here. http://projects.blender.org/tracker/index.php?func=detailaid=25809group_id=9atid=127 Re #[4], IDPropertyGroups can be defined like operators. Probably nobody did this because adding properties to existing types Scene, Group, Mesh etc.. cant be done this way. - Campbell On Thu, Jan 27, 2011 at 1:10 AM, Martin Poirier the...@yahoo.com wrote: Hi, After talking with Campbell at length this morning (my morning), here's what was agreed upon. - Keep using a metaclass to build a list of extension type per module - The automatic registration system should support both runtime and define time registration. [1] - Turning on or off automatic registration should require *at most* a single function call at the end of a module. [2] The only last decision to take, as far as I understood (and I hope there wasn't a misunderstanding) is whether or not the automatic method should be opt in or opt out. I've made some changes to the automatic system today (patch attached) that would make it easy to support opt in or opt out painlessly. It also demonstrates how the metaclass can be used to gather more information about the types (file and line where they are defined). Regards, Martin Don't read the following unless you want boring details on stuff most people don't care about (and shouldn't) === [0] Currently, IDPropGroups are treated separately than other types. That was a work around for previous coding practices and needs to be removed. [1] Define time is the usual case: built in modules and addons. Runtime is both for definitions during a call to a module and for text window execution (although the later one could probably work like built-in modules). [2] Something like bpy.utils.manual_registration() to turn off or bpy.utils.register(__name__) to register all types in a module. This removes the need of doing shenanigans like calling the module's register method if __name__ == main to support text window execution and whatnot, which, IMHO is a good thing. [3] I also suggested we support optional register and unregister class methods in RNA types. This would help remove code entropy and make the definitions more self contained (for example, a class defining OBJ import could also contain the code to add and remove itself from menus instead of having it in the module's function). The jury is still out on whether that's a good idea or not. [4] We both agreed that IDPropGroups properties should be defined using the same syntax as operator properties (if possible) instead of having to add them post registration. Campbell said he'd try his hand at that later this week (IIRC). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34732] trunk/blender/release/bin/ blender-thumbnailer.py: patch [#25972] blender-thumbnailer.py: GVFS support
Turns out that Scons isn't set up for dynamic libs: it can only copy
them in from the /libs folder. The thumb handler residing there is
probably for the best anyway, since the Windows SDK is needed to build it.
Pre-compiling also solves the arch problem in my last message.
On 10/02/2011 5:11, Tom Edwards wrote:
Thanks Campbell. There is another issue I forgot: unlike Blender itself,
an x86 thumb handler won't run on x64 Windows. Can the build systems
handle this?
On 10/02/2011 12:57, Campbell Barton wrote:
@Xavier,
blender-thumbnailer.py is a standalone script and runs without blender
in py2.x - 3.x
its included so tools may extract thumbnails from blender without
loading blender.
blender does this internally in C, from thumbs_blend.c: loadblend_thumb.
@Tom Edwards, there doesn't seem to be a good place for this to go in
blenders source.
For now how about: ./source/tools/windows_thumbnail/ ?
On Wed, Feb 9, 2011 at 9:20 PM, Tom Edwardscont...@steamreview.org wrote:
Thumbs are generated by Blender on save and stored in the file as RGBA
pixels. There is no risk.
On this topic, I keep wanting to submit my Windows thumbnail handler but
I don't know where it should go in the source tree. It has to be a
dynamic lib, but it's not exactly external...any suggestions?
On 09/02/2011 2:34, Xavier Thomas wrote:
Hi Campbell,
I would like to know if the Blender thumbnailer deactivate python scripts
inside the blend.
Thumbnailers are big security issues. A malisous .blend on a USB memory
stick could serve as infection vector on all platform. Executing some of
the
py scripts inside would make it too easy.
Xavier
2011/2/9 Campbell Bartonideasma...@gmail.com
Revision: 34732
http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34732
Author: campbellbarton
Date: 2011-02-09 02:09:30 + (Wed, 09 Feb 2011)
Log Message:
---
patch [#25972] blender-thumbnailer.py: GVFS support
from Shinsuke Irie (irie) with some minor edits.
Shinsuke's description from the tracker:
---
I have implemented GVFS framework support of blender-thumbnailer.py which
allows some file managers like Nautilus and Thunar to show thumbnails in
trash or network directories. If Python's gio module is available, the
thumbnailer uses it to access to filesystems mounted via GVFS. This change
shouldn't affect desktop environments other than GNOME and XFCE.
A function gvfs_open() in this patch is defined to solve a stupid
incompatibility between Python file object and GIO Seekable object.
On Ubuntu 10.10, I confirmed thumbnails can be generated for file://,
trash://, sftp://, and smb://.
Modified Paths:
--
trunk/blender/release/bin/blender-thumbnailer.py
Modified: trunk/blender/release/bin/blender-thumbnailer.py
===
--- trunk/blender/release/bin/blender-thumbnailer.py2011-02-09
02:09:25
UTC (rev 34731)
+++ trunk/blender/release/bin/blender-thumbnailer.py2011-02-09
02:09:30
UTC (rev 34732)
@@ -24,27 +24,49 @@
Thumbnailer runs with python 2.6 and 3.x.
To run automatically with nautilus:
gconftool --type boolean --set
/desktop/gnome/thumbnailers/application@x-blender/enable true
- gconftool --type string --set
/desktop/gnome/thumbnailers/application@x-blender/command
blender-thumbnailer.py %i %o
+ gconftool --type string --set
/desktop/gnome/thumbnailers/application@x-blender/command
blender-thumbnailer.py %u %o
import struct
+def open_wrapper_get():
+ wrap OS spesific read functionality here, fallback to 'open()'
+
+
+def open_gio(path, mode):
+g_file = gio.File(path).read()
+g_file.orig_seek = g_file.seek
+
+def new_seek(offset, whence=0):
+return g_file.orig_seek(offset, [1, 0, 2][whence])
+
+g_file.seek = new_seek
+return g_file
+
+try:
+import gio
+return open_gio
+except ImportError:
+return open
+
+
def blend_extract_thumb(path):
import os
+open_wrapper = open_wrapper_get()
# def MAKE_ID(tag): ord(tag[0])24 | ord(tag[1])16 |
ord(tag[2])8
| ord(tag[3])
REND = 1145980242 # MAKE_ID(b'REND')
TEST = 1414743380 # MAKE_ID(b'TEST')
-blendfile = open(path, 'rb')
+blendfile = open_wrapper(path, 'rb')
head = blendfile.read(12)
if head[0:2] == b'\x1f\x8b': # gzip magic
import gzip
blendfile.close()
-blendfile = gzip.open(path, 'rb')
+blendfile = gzip.GzipFile('', 'rb', 0, open_wrapper(path, 'rb'))
head = blendfile.read(12)
if not head.startswith(b'BLENDER'):
___
Bf-blender-cvs mailing list
bf-blender-...@blender.org
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
___
Re: [Bf-committers] RNA Extension Registration
Hi, I'd also be interested in knowing what, specifically, Campbell thinks is overkill. And you're right, opt in could be a bit simplified, depending on how far we want to go (have the runtime case be completely manual or not, I have ideas to handle both). Martin --- On Thu, 2/10/11, Brecht Van Lommel brechtvanlom...@pandora.be wrote: From: Brecht Van Lommel brechtvanlom...@pandora.be Subject: Re: [Bf-committers] RNA Extension Registration To: bf-blender developers bf-committers@blender.org Received: Thursday, February 10, 2011, 4:59 PM Hi, So, looking at this again, as I understand it, the main decision that needs to be taken is if we want auto registration to be opt-in or opt-out. The only difference would be a few standard lines at the end of scripts. I prefer this to be opt-in personally. Regarding the implementation, that's hard to judge for me, but I guess that in the case we decide on opt-in and that means the implementation can be simplified in places, then it's logical to do so. Brecht. On Thu, Jan 27, 2011 at 9:57 AM, Campbell Barton ideasma...@gmail.com wrote: Hi Martin, Just looked into your patch and while its improved and more flexible improvement its still creating an environment which is overkill IMHO. This goes back to the problem that you want to keep auto-registration and I'm not convinced its better then an api which gives a convenience registration function for script authors to access. This can simply be solved by collecting classes and having a single function to register them, anything more then this increases complexity of our internals significantly and only means we avoid a few lines at the end of the scripts. Updated my patch posted earlier to the ML, with minor changes. - Uses metaclass to collect classes as we agreed. - Includes line of class definition to include on registration errors (like you added with yours). Attached the updated patch here. http://projects.blender.org/tracker/index.php?func=detailaid=25809group_id=9atid=127 Re #[4], IDPropertyGroups can be defined like operators. Probably nobody did this because adding properties to existing types Scene, Group, Mesh etc.. cant be done this way. - Campbell On Thu, Jan 27, 2011 at 1:10 AM, Martin Poirier the...@yahoo.com wrote: Hi, After talking with Campbell at length this morning (my morning), here's what was agreed upon. - Keep using a metaclass to build a list of extension type per module - The automatic registration system should support both runtime and define time registration. [1] - Turning on or off automatic registration should require *at most* a single function call at the end of a module. [2] The only last decision to take, as far as I understood (and I hope there wasn't a misunderstanding) is whether or not the automatic method should be opt in or opt out. I've made some changes to the automatic system today (patch attached) that would make it easy to support opt in or opt out painlessly. It also demonstrates how the metaclass can be used to gather more information about the types (file and line where they are defined). Regards, Martin Don't read the following unless you want boring details on stuff most people don't care about (and shouldn't) === [0] Currently, IDPropGroups are treated separately than other types. That was a work around for previous coding practices and needs to be removed. [1] Define time is the usual case: built in modules and addons. Runtime is both for definitions during a call to a module and for text window execution (although the later one could probably work like built-in modules). [2] Something like bpy.utils.manual_registration() to turn off or bpy.utils.register(__name__) to register all types in a module. This removes the need of doing shenanigans like calling the module's register method if __name__ == main to support text window execution and whatnot, which, IMHO is a good thing. [3] I also suggested we support optional register and unregister class methods in RNA types. This would help remove code entropy and make the definitions more self contained (for example, a class defining OBJ import could also contain the code to add and remove itself from menus instead of having it in the module's function). The jury is still out on whether that's a good idea or not. [4] We both agreed that IDPropGroups properties should be defined using the same syntax as operator properties (if possible) instead of having to add them post registration. Campbell said he'd try his hand at that later this week (IIRC). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33522] trunk/blender/source/gameengine/ Ketsji: BGE BugFix: [#21246] Some values for ipoactuator. frameEnd and frameStart make ip
I take Campbell's reply as a +1 and since I can't see any draw-sides on that I just committed it. Carsten, please put it in a great use ;) Some people may say that the ui is a bit clunky with the decimals, I have no strong opinions here. -- Dalai 2011/2/7 Carsten Wartmann c...@blenderbuch.de: Am 07.02.2011 22:23, schrieb Dalai Felinto: Just for the records. ... That said we have the Property playmode which most of the time has a float on it. So to have floats there wouldn't be a problem. However Yes, I used this many times where a resolution on a frame was not enough. Blender itself does not allow to change the current frame to a float. Hmm? I don't think I understand this. I can put a key on 12.42 seconds or frames or whatever, and yes it probably does not make sense in rendering to have half frames, but it does in the BGE I think. Carsten -- Carsten Wartmann: Autor - Dozent - 3D - Grafik Homepage: http://blenderbuch.de/ Das Blender-Buch: http://blenderbuch.de/redirect.html ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34765] trunk/blender/release/scripts: patch [#25809] Auto-Registration as utility function.
HEY!! How about letting addon developers know how this new opt-in implementation is supposed to work before ploughing ahead and seriously breaking everything, again. I'm not arguing here about whether this is better or not - but as it stands now I've no idea now how to initalise my addon ! Yours sincerely annoyed, again, Doug. On 10 February 2011 23:48, Campbell Barton ideasma...@gmail.com wrote: Revision: 34765 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34765 Author: campbellbarton Date: 2011-02-10 23:48:22 + (Thu, 10 Feb 2011) Log Message: --- patch [#25809] Auto-Registration as utility function. This removes auto-registration, committed by Martin r30961. Realize this is a contentious topic but Brecht and myself both would rather opt-in registration. TODO: - addons need updating. - class list will be modified to use weakrefs (should have been done for existing system too). - will move bpy.types.(un)register functions into bpy.utils.(un)register_class, currently including these functions in a type list is internally ugly, scripts which loop over types also need to check for these. Revision Links: -- http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=30961 Modified Paths: -- trunk/blender/release/scripts/io/netrender/ui.py trunk/blender/release/scripts/modules/bpy/utils.py trunk/blender/release/scripts/modules/bpy_types.py trunk/blender/release/scripts/op/animsys_update.py trunk/blender/release/scripts/op/fcurve_euler_filter.py trunk/blender/release/scripts/op/image.py trunk/blender/release/scripts/op/mesh.py trunk/blender/release/scripts/op/nla.py trunk/blender/release/scripts/op/object.py trunk/blender/release/scripts/op/object_align.py trunk/blender/release/scripts/op/object_randomize_transform.py trunk/blender/release/scripts/op/presets.py trunk/blender/release/scripts/op/screen_play_rendered_anim.py trunk/blender/release/scripts/op/sequencer.py trunk/blender/release/scripts/op/uv.py trunk/blender/release/scripts/op/uvcalc_follow_active.py trunk/blender/release/scripts/op/uvcalc_smart_project.py trunk/blender/release/scripts/op/vertexpaint_dirt.py trunk/blender/release/scripts/op/wm.py trunk/blender/release/scripts/ui/properties_animviz.py trunk/blender/release/scripts/ui/properties_data_armature.py trunk/blender/release/scripts/ui/properties_data_bone.py trunk/blender/release/scripts/ui/properties_data_camera.py trunk/blender/release/scripts/ui/properties_data_curve.py trunk/blender/release/scripts/ui/properties_data_empty.py trunk/blender/release/scripts/ui/properties_data_lamp.py trunk/blender/release/scripts/ui/properties_data_lattice.py trunk/blender/release/scripts/ui/properties_data_mesh.py trunk/blender/release/scripts/ui/properties_data_metaball.py trunk/blender/release/scripts/ui/properties_data_modifier.py trunk/blender/release/scripts/ui/properties_game.py trunk/blender/release/scripts/ui/properties_material.py trunk/blender/release/scripts/ui/properties_object.py trunk/blender/release/scripts/ui/properties_object_constraint.py trunk/blender/release/scripts/ui/properties_particle.py trunk/blender/release/scripts/ui/properties_physics_cloth.py trunk/blender/release/scripts/ui/properties_physics_common.py trunk/blender/release/scripts/ui/properties_physics_field.py trunk/blender/release/scripts/ui/properties_physics_fluid.py trunk/blender/release/scripts/ui/properties_physics_smoke.py trunk/blender/release/scripts/ui/properties_physics_softbody.py trunk/blender/release/scripts/ui/properties_render.py trunk/blender/release/scripts/ui/properties_scene.py trunk/blender/release/scripts/ui/properties_texture.py trunk/blender/release/scripts/ui/properties_world.py trunk/blender/release/scripts/ui/space_console.py trunk/blender/release/scripts/ui/space_dopesheet.py trunk/blender/release/scripts/ui/space_filebrowser.py trunk/blender/release/scripts/ui/space_graph.py trunk/blender/release/scripts/ui/space_image.py trunk/blender/release/scripts/ui/space_info.py trunk/blender/release/scripts/ui/space_logic.py trunk/blender/release/scripts/ui/space_nla.py trunk/blender/release/scripts/ui/space_node.py trunk/blender/release/scripts/ui/space_outliner.py trunk/blender/release/scripts/ui/space_sequencer.py trunk/blender/release/scripts/ui/space_text.py trunk/blender/release/scripts/ui/space_time.py trunk/blender/release/scripts/ui/space_userpref.py trunk/blender/release/scripts/ui/space_userpref_keymap.py trunk/blender/release/scripts/ui/space_view3d.py trunk/blender/release/scripts/ui/space_view3d_toolbar.py Modified: trunk/blender/release/scripts/io/netrender/ui.py
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34765] trunk/blender/release/scripts: patch [#25809] Auto-Registration as utility function.
I'll be reverting this tomorrow evening if it's not done before that. This is not the kind of change that you push in without warning anybody about it first and documenting things. This shows a complete lack of respect for everyone involved, especially after people just recently asked to be warned in case of changes even less breaking than this. I can't think of a word to describe how seriously disappointed I am right now. Martin --- On Thu, 2/10/11, Doug Hammond doughamm...@hamsterfight.co.uk wrote: From: Doug Hammond doughamm...@hamsterfight.co.uk Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34765] trunk/blender/release/scripts: patch [#25809] Auto-Registration as utility function. To: bf-committers@blender.org Received: Thursday, February 10, 2011, 7:09 PM HEY!! How about letting addon developers know how this new opt-in implementation is supposed to work before ploughing ahead and seriously breaking everything, again. I'm not arguing here about whether this is better or not - but as it stands now I've no idea now how to initalise my addon ! Yours sincerely annoyed, again, Doug. On 10 February 2011 23:48, Campbell Barton ideasma...@gmail.com wrote: Revision: 34765 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34765 Author: campbellbarton Date: 2011-02-10 23:48:22 + (Thu, 10 Feb 2011) Log Message: --- patch [#25809] Auto-Registration as utility function. This removes auto-registration, committed by Martin r30961. Realize this is a contentious topic but Brecht and myself both would rather opt-in registration. TODO: - addons need updating. - class list will be modified to use weakrefs (should have been done for existing system too). - will move bpy.types.(un)register functions into bpy.utils.(un)register_class, currently including these functions in a type list is internally ugly, scripts which loop over types also need to check for these. Revision Links: -- http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=30961 Modified Paths: -- trunk/blender/release/scripts/io/netrender/ui.py trunk/blender/release/scripts/modules/bpy/utils.py trunk/blender/release/scripts/modules/bpy_types.py trunk/blender/release/scripts/op/animsys_update.py trunk/blender/release/scripts/op/fcurve_euler_filter.py trunk/blender/release/scripts/op/image.py trunk/blender/release/scripts/op/mesh.py trunk/blender/release/scripts/op/nla.py trunk/blender/release/scripts/op/object.py trunk/blender/release/scripts/op/object_align.py trunk/blender/release/scripts/op/object_randomize_transform.py trunk/blender/release/scripts/op/presets.py trunk/blender/release/scripts/op/screen_play_rendered_anim.py trunk/blender/release/scripts/op/sequencer.py trunk/blender/release/scripts/op/uv.py trunk/blender/release/scripts/op/uvcalc_follow_active.py trunk/blender/release/scripts/op/uvcalc_smart_project.py trunk/blender/release/scripts/op/vertexpaint_dirt.py trunk/blender/release/scripts/op/wm.py trunk/blender/release/scripts/ui/properties_animviz.py trunk/blender/release/scripts/ui/properties_data_armature.py trunk/blender/release/scripts/ui/properties_data_bone.py trunk/blender/release/scripts/ui/properties_data_camera.py trunk/blender/release/scripts/ui/properties_data_curve.py trunk/blender/release/scripts/ui/properties_data_empty.py trunk/blender/release/scripts/ui/properties_data_lamp.py trunk/blender/release/scripts/ui/properties_data_lattice.py trunk/blender/release/scripts/ui/properties_data_mesh.py trunk/blender/release/scripts/ui/properties_data_metaball.py trunk/blender/release/scripts/ui/properties_data_modifier.py trunk/blender/release/scripts/ui/properties_game.py trunk/blender/release/scripts/ui/properties_material.py trunk/blender/release/scripts/ui/properties_object.py trunk/blender/release/scripts/ui/properties_object_constraint.py trunk/blender/release/scripts/ui/properties_particle.py trunk/blender/release/scripts/ui/properties_physics_cloth.py trunk/blender/release/scripts/ui/properties_physics_common.py trunk/blender/release/scripts/ui/properties_physics_field.py trunk/blender/release/scripts/ui/properties_physics_fluid.py trunk/blender/release/scripts/ui/properties_physics_smoke.py trunk/blender/release/scripts/ui/properties_physics_softbody.py trunk/blender/release/scripts/ui/properties_render.py trunk/blender/release/scripts/ui/properties_scene.py trunk/blender/release/scripts/ui/properties_texture.py trunk/blender/release/scripts/ui/properties_world.py trunk/blender/release/scripts/ui/space_console.py
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [34765] trunk/blender/release/scripts: patch [#25809] Auto-Registration as utility function.
Hi Doug, I should have been more clear that I'll be updating addons next. In most cases 'bpy.utils.register_module' / 'bpy.utils.unregister_module' just need adding. example from OBJ i/o (menu registration functions we're already there). def register(): bpy.utils.register_module(__name__) bpy.types.INFO_MT_file_import.append(menu_func_import) bpy.types.INFO_MT_file_export.append(menu_func_export) def unregister(): bpy.utils.unregister_module(__name__) bpy.types.INFO_MT_file_import.remove(menu_func_import) bpy.types.INFO_MT_file_export.remove(menu_func_export) On Fri, Feb 11, 2011 at 12:09 AM, Doug Hammond doughamm...@hamsterfight.co.uk wrote: HEY!! How about letting addon developers know how this new opt-in implementation is supposed to work before ploughing ahead and seriously breaking everything, again. I'm not arguing here about whether this is better or not - but as it stands now I've no idea now how to initalise my addon ! Yours sincerely annoyed, again, Doug. On 10 February 2011 23:48, Campbell Barton ideasma...@gmail.com wrote: Revision: 34765 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=34765 Author: campbellbarton Date: 2011-02-10 23:48:22 + (Thu, 10 Feb 2011) Log Message: --- patch [#25809] Auto-Registration as utility function. This removes auto-registration, committed by Martin r30961. Realize this is a contentious topic but Brecht and myself both would rather opt-in registration. TODO: - addons need updating. - class list will be modified to use weakrefs (should have been done for existing system too). - will move bpy.types.(un)register functions into bpy.utils.(un)register_class, currently including these functions in a type list is internally ugly, scripts which loop over types also need to check for these. Revision Links: -- http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=30961 Modified Paths: -- trunk/blender/release/scripts/io/netrender/ui.py trunk/blender/release/scripts/modules/bpy/utils.py trunk/blender/release/scripts/modules/bpy_types.py trunk/blender/release/scripts/op/animsys_update.py trunk/blender/release/scripts/op/fcurve_euler_filter.py trunk/blender/release/scripts/op/image.py trunk/blender/release/scripts/op/mesh.py trunk/blender/release/scripts/op/nla.py trunk/blender/release/scripts/op/object.py trunk/blender/release/scripts/op/object_align.py trunk/blender/release/scripts/op/object_randomize_transform.py trunk/blender/release/scripts/op/presets.py trunk/blender/release/scripts/op/screen_play_rendered_anim.py trunk/blender/release/scripts/op/sequencer.py trunk/blender/release/scripts/op/uv.py trunk/blender/release/scripts/op/uvcalc_follow_active.py trunk/blender/release/scripts/op/uvcalc_smart_project.py trunk/blender/release/scripts/op/vertexpaint_dirt.py trunk/blender/release/scripts/op/wm.py trunk/blender/release/scripts/ui/properties_animviz.py trunk/blender/release/scripts/ui/properties_data_armature.py trunk/blender/release/scripts/ui/properties_data_bone.py trunk/blender/release/scripts/ui/properties_data_camera.py trunk/blender/release/scripts/ui/properties_data_curve.py trunk/blender/release/scripts/ui/properties_data_empty.py trunk/blender/release/scripts/ui/properties_data_lamp.py trunk/blender/release/scripts/ui/properties_data_lattice.py trunk/blender/release/scripts/ui/properties_data_mesh.py trunk/blender/release/scripts/ui/properties_data_metaball.py trunk/blender/release/scripts/ui/properties_data_modifier.py trunk/blender/release/scripts/ui/properties_game.py trunk/blender/release/scripts/ui/properties_material.py trunk/blender/release/scripts/ui/properties_object.py trunk/blender/release/scripts/ui/properties_object_constraint.py trunk/blender/release/scripts/ui/properties_particle.py trunk/blender/release/scripts/ui/properties_physics_cloth.py trunk/blender/release/scripts/ui/properties_physics_common.py trunk/blender/release/scripts/ui/properties_physics_field.py trunk/blender/release/scripts/ui/properties_physics_fluid.py trunk/blender/release/scripts/ui/properties_physics_smoke.py trunk/blender/release/scripts/ui/properties_physics_softbody.py trunk/blender/release/scripts/ui/properties_render.py trunk/blender/release/scripts/ui/properties_scene.py trunk/blender/release/scripts/ui/properties_texture.py trunk/blender/release/scripts/ui/properties_world.py trunk/blender/release/scripts/ui/space_console.py trunk/blender/release/scripts/ui/space_dopesheet.py trunk/blender/release/scripts/ui/space_filebrowser.py trunk/blender/release/scripts/ui/space_graph.py trunk/blender/release/scripts/ui/space_image.py trunk/blender/release/scripts/ui/space_info.py
Re: [Bf-committers] bugs?
I've been building Clang/LLVM from SVN for a while and tried to fix
these warnings/bugs and we have blender down to 670 warnings from
1153.
Old reports: http://www.graphicall.org/ftp/ideasman42/2011-01-07-2/
If anyone on Linux is interested, heres how I setup blender/clang.
http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang
There were certainly cases where functions ran for no reason and could
be commented/removed but I think these are all resolved now.
The reason I didn't continue to clear the dead assignment warnings is
it would do more harm then good IMHO.
Example
--
static void stats_background(void *UNUSED(arg), RenderStats *rs)
{
char str[400], *spos= str;
--- snip ---
spos+= sprintf(spos, Fra:%d Mem:%.2fM (%.2fM, peak %.2fM) ,
rs-cfra,megs_used_memory, mmap_used_memory, megs_peak_memory);
if(rs-curfield)
spos+= sprintf(spos, Field %d , rs-curfield);
if(rs-curblur)
spos+= sprintf(spos, Blur %d , rs-curblur);
if(rs-infostr) {
spos+= sprintf(spos, | %s, rs-infostr);
}
else {
if(rs-tothalo)
spos+= sprintf(spos, Sce: %s Ve:%d Fa:%d Ha:%d La:%d,
rs-scenename, rs-totvert, rs-totface, rs-tothalo, rs-totlamp);
else
spos+= sprintf(spos, Sce: %s Ve:%d Fa:%d La:%d,
rs-scenename, rs-totvert, rs-totface, rs-totlamp);
}
printf(%s\n, str);
}
--
You can tell that the last 3 'spos +=' are dead assignments, but if
these are removed, a developer might add a new string later and forget
to add one of them back.
Same goes for 'yofs += ' with many interface functions.
In some cases I commented the assignment, eg:
/*spos+=*/ sprintf(spos, | %s, rs-infostr);
But this is only good if the variable its self is commented otherwise
it could be used later where the developer needs to remember to
uncomment the assignment which isn't always obvious.
To quiet Clang's dead assignment warnings we could do this at the end
of functions...
--
(void)spos;
}
--
It would be nice to quiet the warnings so we know all warnings are
_real_ problems and real bugs don't get mixed up with harmless reports
but this also adds cruft which is why I didn't go ahead with it.
If other devs think its worth trying to get even fewer warnings we
could in the same way its nice to have 0 compiler warnings, but at
this point I feel we're getting diminishing returns for making such
small changes.
- Campbell
On Fri, Feb 11, 2011 at 1:10 AM, Tom M letter...@gmail.com wrote:
When using CLangs static checker on Blender,
there are a large number of 'dead stores' - variables that are
assigned a value, but the variable is never used.
Thus these are items that either had functionality at one point, but
no longer do. Or are intended to have functionality that is not yet
in use.
Almost none of them are commented so it isn't readily determined which
of the two cases it is. There are about 200 instances of dead stores
in the code.
Here are some examples (filename, then variable name, and the line
number). In my view they should either be commented, commented out or
deleted.
Having them in the code can make it confusing to read since you try
and track where and how the variable is used.
anim_channel_defines.c
type - 2614 ok (unneeded ++)
enabled - 3121
text - 3241
offset - 3266, 3271
anim_channels_edit.c
prevLevel - 490
ymin - 1766, 1770
fmodifier_ui.c
col - 117
row - 523, 541
keyframes_draw.c
abp - 363
drawgpencil.c
actlay - 540
gpencil_paint.c
ok - 1356
interface.c
okwidth - 2087
str - 2193
interface_handlers.c
retval - 1798
softmin - 2237
softmax - 2238
temp - 2399
screen_my - 2424
click - 2786
offsx - 2380
offsy - 2381
changed - 3480, 3511
dx - 3603, 3686
yfac - 3695
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] bugs?
Hah: diminishing returns for making such small changes. That doesn't sound right, I should have mentioned that testing the small changes do what you want takes a long time, (I run clang overnight). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
