Re: [Bf-committers] overall milestones and progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7.9.2010 20:18, Muhamad Faizol Abd. Halim wrote: Hi all, sorry if this is asked already. But is there any overall milestones/targets documentations and its status (for both the main and branches) available anywhere on the net? You might find the following links useful: * http://wiki.blender.org/index.php/Dev:2.5/Source * http://www.blender.org/development/release-logs/blender-250/ /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMh0SqAAoJEKtfN7KsE0TtuToH/3K/D3m9rIbVjiB6QGdJJo9f 677hGMMjnHt7IENxEX7eSo8LYqlyE0am1fBlYz/SizYc6Tqv+t8Axe4/FaSHqJq7 fnS13PCa+BdVeL0DdOW/K98VLsFaEwigwM/OCaW3mPG2qZA04QejlOnIYPVmGhxb NkK9SR3X0w7sIiX/LqbGXx7WjFk+hknCgSPN/ZoAiXc3QbvXkK4BS1mKLN049q3U LqXhSnLn0BEaGagosPSJGqqm85rK1nGjN3LcxMy957ku/EeohCcFe9sOJ5wJOZOc FuhCNzL1wO9xI0U3zq1IqoTHdlkcdajSZnaqMrIcppEj7PwCDFm+kC68PQ5IlTY= =fA9h -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Double vs. single quotes in RNA paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2.9.2010 13:43, Lukas Tönne wrote: I had a bit of hair-pulling yesterday when trying to use the RNA_path_resolve function in nodes socket buttons (i.e. not in the console). It turned out i was entering collection selector strings with single quotes instead of double quotes: objects['blabla'].data instead of objects[blabla].data snip Here's a patch: https://projects.blender.org/tracker/index.php?func=detailaid=23632group_id=9atid=127 Applied in r31826. Thanks. /Nathan - -- Nathan Letwory Letwory Interactive http://www.letworyinteractive.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMh0zFAAoJEKtfN7KsE0Tt7ksH/iJ5tT4VMesiq5gY37iu4UuJ yl7eY7NW69MnyfBPK9QC+RgQrDN52R6MAnMSOGVlhL/78MKlcYwSI7/jceT8EGTj VWdVHT+3JZyJlB4nF3R1JonyX92bRzkPSTIwCH7ZovAcVpXEP4eRAn+nD+x5IMGO J5SoD8WVakpz8u5QQlHAzOwAVtmRjN1sCulS8V3JFSQ+yAKdhCdN8CcnZayZwwLO BLhxiopvEET9ZemaazWbb9/7x6gIaErvK+VZC6kLK4IOzY6Csr/VswMas2VHwM8P U4Mkg/+Vgt2PKNaCcnOio5/6QotZUKU/Myc3ZlnzCD+gk+yTABBPAjBJi8J3fJk= =XjBr -END PGP SIGNATURE- ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] BLF_draw_default not working
I have never programmed in blender before. so I am unfamiliar with how blender works. Anyway I was playing with screencast and noticed you could not see users cursor. I decided to fix this by adding a cursor drawn in opengl(which would get saved in the video file) and add a display of key's being pressed I just wanted to do a quick job by doing it just before the buffer was flipped. so in wm_window.c in void wm_window_swap_buffers(wmWindow *win) i made a triangle at cursor position. all well and good and it worked. I then added a linked list adding an element every time a key was pressed removing it when it was lifted which worked all good. Then i tried to print text to the screen. someone told me BLF_draw_default was the way to go And no matter how i call it. it will not work even something like BLF_draw_default(2, 2, 0.0f, x); does not work I've been going crazy trying to get it works for hours and hours. If anyone can tell me how to get it to work or why it wont work when being called in void wm_window_swap_buffers(wmWindow *win) I will be extremely grateful. here is a quick look of what i have so far http://www.youtube.com/watch?v=U5eyYMmZA4s ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] PyRNA type definition changes (postpone beta until end of week)
Hi, Unless your interested in the python api, this message is just to say there are some changes to make before the next beta and Id like to postpone the upcoming beta a few days. Ton Nathan are ok with this so mailing the list since last meeting we agreed on a beta mid-week. *** PyAPI Enthusiasts read on! *** The reason for this is how we define properties in python is currently inconsistent, I was never really happy with it, and it basically evolved to be the way it is now but without much design. Recently users on IRC have been asking me about this and having to explain this to others made me realize we really need to fix this. Dan Eicher, Nathan and I discussed this, Ill try summarize the topic briefly and give a solution Nathan and I are happy with. There are 2 things I dont like about the current property definition system. 1) inconsistency between operators and types class Operator(bpy.types.Operator): myprop = bpy.props.BoolProperty() and existing classes bpy.types.Scene.BoolProperty(attr=myprop) The main difference with this is one use of BoolProperty returns a property, another doesn't but adds it into the class from which its called. 2) class methods in python are available on instances. this is OK ends up being confusing since we CAN have properties only on 1 object. So... bpy.types.Scene.BoolProperty(attr=myprop) Is the same as... context.scene.BoolProperty(attr=myprop) But it looks like it might do... context.scene[pyprop] = True # current python method to add a property to a single object --- Proposed solution Follow the way operators work, treat properties as class attributes so... bpy.types.Scene.BoolProperty(attr=myprop) bpy.types.Scene.RemoveProperty(attr=myprop) ...is replaced by bpy.types.Scene.myprop = bpy.props.BoolProperty() del bpy.types.Scene.myprop class NetRenderSettings(bpy.types.IDPropertyGroup): pass NetRenderSettings.StringProperty( attr=server_address, name=Server address) ... is replaced by class NetRenderSettings(bpy.types.IDPropertyGroup): server_address = bpy.props.StringProperty( attr=, name=Server address) ...or this should work too class NetRenderSettings(bpy.types.IDPropertyGroup): pass NetRenderSettings.server_address = bpy.props.StringProperty( attr=, name=Server address) Another change to help our api be less confusing is to have operator properties directly accessible. class Operator(bpy.types.Operator): myprop = bpy.props.BoolProperty() def execute(self, context): ... this line print(self.properties.myprop) ...could be written as print(self.myprop) At the moment print(self.myprop) will print the property definition, but not the property (which is what you want!) I'd like to keep self.properties available since its how operators work internally and can be passed as keyword arguments, so this change is mostly for convent access. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyRNA type definition changes (postpone beta until end of week)
Hi Campbell, On Thu, Sep 9, 2010 at 9:18 AM, Campbell Barton ideasma...@gmail.com wrote: --- Proposed solution Follow the way operators work, treat properties as class attributes so... bpy.types.Scene.BoolProperty(attr=myprop) bpy.types.Scene.RemoveProperty(attr=myprop) ...is replaced by bpy.types.Scene.myprop = bpy.props.BoolProperty() del bpy.types.Scene.myprop It is certainly less verbose, but didn't we recently move away from treating properties as attributes in the BGE? For consistency, maybe it should be: bpy.types.Scene[myprop] = bpy.props.BoolProperty() del bpy.types.Scene[myprop] On the other hand, using attributes might be better if properties are more formally defined than in the BGE. Cheers, Alex ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyRNA type definition changes (postpone beta until end of week)
On Thu, Sep 9, 2010 at 12:18 AM, Alex Fraser a...@phatcore.com wrote: Hi Campbell, On Thu, Sep 9, 2010 at 9:18 AM, Campbell Barton ideasma...@gmail.com wrote: --- Proposed solution Follow the way operators work, treat properties as class attributes so... bpy.types.Scene.BoolProperty(attr=myprop) bpy.types.Scene.RemoveProperty(attr=myprop) ...is replaced by bpy.types.Scene.myprop = bpy.props.BoolProperty() del bpy.types.Scene.myprop It is certainly less verbose, but didn't we recently move away from treating properties as attributes in the BGE? For consistency, maybe it should be: bpy.types.Scene[myprop] = bpy.props.BoolProperty() del bpy.types.Scene[myprop] On the other hand, using attributes might be better if properties are more formally defined than in the BGE. Cheers, Alex in fact the BGE and 2.5 rna api are the same in this way. Both allow defining user properties via dictionary like syntax, this bypasses the rna api. obj[someprop] = Value But the BGE doesnt have a way to extend the the internal types (beyond typical python subclassing) as we do with RNA so I dont think theres a conflict here. assigning attributes to a class works in pure python too, eg. class Foo: ... pass ... Foo.MyProp = property(lambda self: Hello World) inst = Foo() print(inst.MyProp) Hello World So you can see that assigning properties this way is in keeping with the rest of python. The main problem is that we now need to override the setattr/getattr/delattr using a metaclass and make a special exception when a blender property is assigned, looking into this now. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyRNA type definition changes (postpone beta until end of week)
Hi Campbell --snip Another change to help our api be less confusing is to have operator properties directly accessible. class Operator(bpy.types.Operator): myprop = bpy.props.BoolProperty() def execute(self, context): ... this line print(self.properties.myprop) ...could be written as print(self.myprop) At the moment print(self.myprop) will print the property definition, but not the property (which is what you want!) I'd like to keep self.properties available since its how operators work internally and can be passed as keyword arguments, so this change is mostly for convent access. The question that came to mind here (as I mentioned on irc) is that if you *did* want to print/access the property definition, how would you do so if self.myprop just returns the value? cheers Bassam PS- thanks for the mail, it cleared up some things that had been long confusing me re. the api. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Patch #23738: Add function to select all keyframes left/right to current frame in dope sheet
Dear developers, I just added patch #23738 to the patch tracker. This patch add functions to select all keyframes left/right to current frame in dope sheet. Details of the patch: The attached patch add functions to select all keyframes to the left or right of the current frame (including the current frame). This functions are convenient to create or remove space between keyframes, e. g. when you like to insert more frames or slow-down/speed-up some animation step. E. g. to create/remove some space: - select keyframe position - press [ to select all keyframes right to the current selected keyframe - move frames with G The patch do the following: - implement source/blender/editors/space_action/action_select.c:columnselect_action_left_right() - add menu entries Columns Left to Current Frame and Columns Right to Current Frame in the Select menu - add shortcut keys [ and ] for these functions I'm looking forward that someone will review the patch and push it into the repository when you think the patch is OK and useful. Torsten ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PyRNA type definition changes (postpone beta until end of week)
On Thu, Sep 9, 2010 at 2:41 AM, Bassam Kurdali bkurd...@freefactory.org wrote: Hi Campbell --snip Another change to help our api be less confusing is to have operator properties directly accessible. class Operator(bpy.types.Operator): myprop = bpy.props.BoolProperty() def execute(self, context): ... this line print(self.properties.myprop) ...could be written as print(self.myprop) At the moment print(self.myprop) will print the property definition, but not the property (which is what you want!) I'd like to keep self.properties available since its how operators work internally and can be passed as keyword arguments, so this change is mostly for convent access. The question that came to mind here (as I mentioned on irc) is that if you *did* want to print/access the property definition, how would you do so if self.myprop just returns the value? cheers Bassam PS- thanks for the mail, it cleared up some things that had been long confusing me re. the api. operators define StructRNA types once registered so you can do... bpy.types.IMPORT_SCENE_OT_obj.bl_rna.properties[ROTATE_X90] bpy_struct, BooleanProperty(ROTATE_X90) just like... bpy.types.Scene.bl_rna.properties[frame_start] bpy_struct, IntProperty(frame_start) having bl_rna is ugly but needed ATM since the python class and the rna type a different (perhaps they could be made into the same type but its not trivial). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
