Page MenuHome

Fix Copy Full Data Path feature

Authored by Aleksandr Zinovev (raa) on Jul 21 2017, 1:54 PM.



Copy Full Data Path (ctrl+shift+alt+C) feature is useful for new add-on developers.
The problem is that the feature is "hidden" (accessible only by the hotkey) and doesn't work for most buttons.

To fix these issues the patch:

  • Adds a new RMB context menu entry Copy Full Path
  • Adds a new UI_OT_copy_full_path_button operator that uses WM_prop_pystring_from_context function which generates correct paths in most cases.
  • Fixes path generation in WM_prop_pystring_from_context function for:
    • UVEditor
    • Dopesheet
    • Active grease pencil brush
    • GPUFxSettings
    • FileSelectParams

You can check path generation for these buttons. Path generation after the patch:

Diff Detail

rB Blender

Event Timeline

Brecht Van Lommel (brecht) requested changes to this revision.Jul 25 2017, 12:33 AM

Looks generally fine to me.

Is there a reason you created a new operator? The patch would be a bit more backwards compatible and simpler if it kept using the same operator and full_path property as before.

This revision now requires changes to proceed.Jul 25 2017, 12:33 AM

Is there a reason you created a new operator?

@Brecht Van Lommel (brecht), poll methods are differ from each other.
The current Copy Data Path entry is disabled in RMB context menu for most buttons.
Enabling the entry by using the same poll method/operator can confuse the users because it won't generate/copy the path.

But I can update the patch. Let me know what you think.

Looks good to me then, but lets leave this for after 2.79 since we are in bugfixing-only mode.

This revision is now accepted and ready to land.Jul 26 2017, 5:05 PM

@Brecht Van Lommel (brecht), thanks.
Can I at least commit path generation fixes for Blender 2.79?
Users often ask why Blender generates paths like bpy.context....(null) = True

Ok, I think we can consider that part as a bugfix. Just the new operator with new UI strings for translation etc. is too late I think.

Eeek, just found about this. I submitted a similar patch ages ago (D763), although I reorganized scripting related menu entries into a submenu.
I'd be fine with applying this patch and adding the scripting submenu separately. However we should really do both to keep the menu organized.

Regarding the code changes themselves, I'd be fine with them (with a little remark).


I'm in general against such NULL-checks. The caller should be responsible for passing valid (non-NULL) data. If the caller for whatever reason fails to do this, a NULL-check like here would hide the issue, and likely also hide a real bug.
Of course there are exceptions to this rule, like always, but I don't see a need for one here.

Agree. Sub-menu looks better.