[Bf-committers] Getting the associated Blender object name from a uiBut object

[The Simple Carnival]

Actually, I take that back. It's pretty messy to handle that from the 
Restrict View section because it would mean overriding the ability to 
turn on/off the view/select/render icons. Plus, out of the available 
modifier keys (shift, alt, oskey -- ctrl is already taken), only shift 
appears to work on Windows. I need the ability to insert, replace, and 
delete keyframes, and shift can't handle all those cases. So I'm back to 
handling this as right-click "Insert/Replace/Delete Recursive Keyframes" 
menu option.

All I need is the ability to get the name of the associated Blender 
object name from a uiBut object; from there, I know how to handle 
everything else. I'm thinking that the key is this, in particular ptr in 
the second line:

     but = UI_context_active_but_get(C);
     UI_context_active_but_prop_get(C, &ptr, &prop, &index);

(ptr is a PointerRNA, prop is a PropertyRNA.)

I *think* I can somehow take ptr and get the actual blender object it's 
pointing to. However, I'm having difficulty figuring out how to do that. 
Any ideas?

-Jeff



On 8/6/2017 9:39 PM, The Simple Carnival wrote:
> Hi Matt --
>
> Thanks for the tip. I was able to get a proof-of-concept working going 
> off of that code instead of dealing with the uiBut objects. I'll dig 
> more into this, but I think I can make it work.
>
> -Jeff
>
>
> On 8/6/2017 5:15 PM, Matthew Keller wrote:
>> Hi Jeff,
>>
>> Not sure if you've seen this, but there is a way to perform the 
>> 'Restrict View' action in the ui recursively by pressing Ctrl while 
>> clicking. This is the function that enables that behavior as far as I 
>> can tell:
>> https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_outliner/outliner_draw.c;f5f6f9c9ac3ec37ef98eae54464a801c2b7ddcc9$175 
>>
>>
>> They seem to be using the currently selected object and then 
>> iterating through all the objects and checking every time if the 
>> object is a child of the currently selected object.
>>
>> Could you follow that approach by setting the keyframe on the 
>> underlying object as opposed to setting the keyframe on the button? 
>> (there's even logic in there to actually set the keyframe, although 
>> I'm not quite sure under what circumstances that functionality is 
>> triggered)
>>
>> HTH,
>>
>> Matt
>