Python API: Add link/append pre/post handlers. #128279

Merged
Bastien Montagne merged 10 commits from mont29/blender:tmp-link-append-handlers into blender-v4.3-release 2024-10-02 16:44:50 +02:00

The pre handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.

The post handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.

Both handlers are called with a single argument, the link/append
context.

An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.

NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).

Implements #122357


Some quick py example code:

import bpy


def my_handler_pre(lapp_context):
    print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"),
          "\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name,
                                                         "', '".join([l.filepath for l in item.source_libraries]))
                      for item in lapp_context.import_items))

def my_handler_post(lapp_context):
    print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"),
          "\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath)
                      for item in lapp_context.import_items))


bpy.app.handlers.link_append_pre.append(my_handler_pre)
bpy.app.handlers.link_append_post.append(my_handler_post)
The `pre` handler is called after blender internal code is done populating the link/append context with data to be processed, and before this data starts being linked from library files. The `post` handler is called after blender is done linking, and potentailly appending and/or instantiating, the requested data and all of their dependencies. Both handlers are called with a single argument, the link/append context. An new RNA sets of wrappers have been added to expose relevant info from these internal C++ structures. NOTE: !113658 is very similar (but tied to asset drag & drop), whereas this PR is more general (these could probably live hand-in-hand / side- by-side). Implements #122357 ----------------- Some quick py example code: ```python import bpy def my_handler_pre(lapp_context): print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"), "\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name, "', '".join([l.filepath for l in item.source_libraries])) for item in lapp_context.import_items)) def my_handler_post(lapp_context): print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"), "\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath) for item in lapp_context.import_items)) bpy.app.handlers.link_append_pre.append(my_handler_pre) bpy.app.handlers.link_append_post.append(my_handler_post) ```
Bastien Montagne added 1 commit 2024-09-27 19:17:57 +02:00
Python API: Add link/append pre/post handlers.
Some checks reported errors
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
7c53ad5193
The `pre` handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.

The `post` handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.

Both handlers are called with a single argument, the link/append
context.

An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.

NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).
Bastien Montagne requested review from Campbell Barton 2024-09-27 19:18:47 +02:00
Bastien Montagne requested review from Jacques Lucke 2024-09-27 19:18:47 +02:00
Author
Owner

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR128279) when ready.
Author
Owner

@blender-bot package darwin

@blender-bot package darwin
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR128279) when ready.
Contributor

I tried testing this but I couldn't find my way unfortunately. I'm not too good at reading C++ code so I don't know how correctly I made my assumptions, maybe you or someone else can help me out.

Trying to implement functionalities that I laid out in original design issue:

  • I need to access custom properties registered on the ID. One of the most pressing issue was that it was impossible to assign objects unique identifiers, because when appended in other file it might not be unique anymore. I want to be able to access that custom property and change it. Right now it looks like I only have access to few read-only hard-coded props for each appended item, but ideally I should be able to just anything on object. How can I do that in post handler? My only idea was to get the names of items, then iterate over bpy.data.objects to find obj with that name(or UUID if possible) and access that using bpy.context. But I haven't tried this because even if it's possible it is very complicated and potentially expensive to do those iterations.

  • I need a way to access embedded IDs that come with appended object. In my context objects/meshes that are stored as PointerProperties in custom props. For example: I append rig which has prop items such as hair styles registered as pointers, so that I can use custom property to switch between them with my script and only show one at a time. I need to access those objects and set some props on them, for example to set fake user. Is that possible? (It would be possible if above bullet point works correctly. Then I could access like obj.rig_props.embedded_objects and iterate over them to set properties, but maybe it's already possible now with other method)

  • This is long shot, but would it be possible to override operator properties in pre handler? Namely "Instance Object Data" property, enabled by default is causing my add-on a lot of headaches if user forgot to disable it. And state of that property isn't remembered so you have to remember to untick it on every use. Way to override it and always disable in pre handler would be amazing.

I tried testing this but I couldn't find my way unfortunately. I'm not too good at reading C++ code so I don't know how correctly I made my assumptions, maybe you or someone else can help me out. Trying to implement functionalities that I laid out in original design issue: - I need to access custom properties registered on the ID. One of the most pressing issue was that it was impossible to assign objects unique identifiers, because when appended in other file it might not be unique anymore. I want to be able to access that custom property and change it. Right now it looks like I only have access to few read-only hard-coded props for each appended item, but ideally I should be able to just anything on object. How can I do that in post handler? My only idea was to get the names of items, then iterate over `bpy.data.objects` to find obj with that name(or UUID if possible) and access that using `bpy.context`. But I haven't tried this because even if it's possible it is very complicated and potentially expensive to do those iterations. - I need a way to access embedded IDs that come with appended object. In my context objects/meshes that are stored as PointerProperties in custom props. For example: I append rig which has prop items such as hair styles registered as pointers, so that I can use custom property to switch between them with my script and only show one at a time. I need to access those objects and set some props on them, for example to set fake user. Is that possible? (It would be possible if above bullet point works correctly. Then I could access like `obj.rig_props.embedded_objects` and iterate over them to set properties, but maybe it's already possible now with other method) - This is long shot, but would it be possible to override operator properties in pre handler? Namely "Instance Object Data" property, enabled by default is causing my add-on a lot of headaches if user forgot to disable it. And state of that property isn't remembered so you have to remember to untick it on every use. Way to override it and always disable in pre handler would be amazing.
Member

I will test this on Tuesday, I don't know if that's too late, sorry! ;_; But I trust Nick's feedback ❤️

I will test this on Tuesday, I don't know if that's too late, sorry! ;_; But I trust Nick's feedback ❤️
Campbell Barton reviewed 2024-09-30 07:43:51 +02:00
Campbell Barton left a comment
Owner

Generally looks good, notes inline.


In the RNA API using both names LinkAppend seems a bit odd at times, especially for names like linked_appended_id which in in fact means linked-or-appended-id.

We could consider naming that calls this something less awkward.

  • LibraryLink
  • BlendLink
  • BlendFileLink

Documentation can note that "append" is an option for linking which makes the data local after linking (which is what happens internally). Without having to include LinkAppend in all of the names relating to this API... we could even apply this naming to C++ API's although that's out of scope for this PR.

Generally looks good, notes inline. ---- In the RNA API using both names LinkAppend seems a bit odd at times, especially for names like `linked_appended_id` which in in fact means _linked-or-appended-id_. We could consider naming that calls this something less awkward. - LibraryLink - BlendLink - BlendFileLink Documentation can note that "append" is an option for linking which makes the data local after linking (which is what happens internally). Without having to include `LinkAppend` in all of the names relating to this API... _we could even apply this naming to C++ API's although that's out of scope for this PR._
@ -0,0 +30,4 @@
BlendfileLinkAppendContextLibrary *ctx_lib = static_cast<BlendfileLinkAppendContextLibrary *>(
ptr->data);
const size_t str_len = ctx_lib->path.length();
BLI_strncpy(value, ctx_lib->path.c_str(), str_len + 1);

picky can be memcpy, but |'m not that fussed.

*picky* can be `memcpy`, but |'m not _that_ fussed.
mont29 marked this conversation as resolved
@ -0,0 +45,4 @@
BlendfileLinkAppendContextItem *ctx_item = static_cast<BlendfileLinkAppendContextItem *>(
ptr->data);
const size_t str_len = ctx_item->name.length();
BLI_strncpy(value, ctx_item->name.c_str(), str_len + 1);

picky can be memcpy, but |'m not that fussed.

*picky* can be `memcpy`, but |'m not _that_ fussed.
Author
Owner

Would rather not, using BLI_strncpy has some added safety asserts, that actually helped me getting this 'str len arithmetic' right. ;)

Would rather not, using `BLI_strncpy` has some added safety asserts, that actually helped me getting this 'str len arithmetic' right. ;)
mont29 marked this conversation as resolved
@ -0,0 +248,4 @@
RNA_define_verify_sdna(false); /* not in sdna */
prop = RNA_def_property(srna, "path", PROP_STRING, PROP_FILEPATH);

Prefer filepath for consistency, making it clear this isn't related to other kinds of paths.

Prefer `filepath` for consistency, making it clear this isn't related to other kinds of paths.
mont29 marked this conversation as resolved
@ -0,0 +282,4 @@
RNA_define_verify_sdna(false); /* not in sdna */
prop = RNA_def_property(srna, "id_name", PROP_STRING, PROP_NONE);

Could call this name & type ? (the id_ prefix seems a bit redundant).

Or it could be name & id_type since the id_type is a more specific value that doesn't have equivalents on bpy.types.ID instances.

Could call this `name` & `type` ? (the `id_` prefix seems a bit redundant). Or it could be `name` & `id_type` since the `id_type` is a more specific value that doesn't have equivalents on `bpy.types.ID` instances.
Author
Owner

name and id_type match the ID struct API, so think this is the best option.

`name` and `id_type` match the `ID` struct API, so think this is the best option.
mont29 marked this conversation as resolved
@ -0,0 +371,4 @@
prop, "Link Info", "Various status info about an item after it has been linked");
RNA_def_property_enum_funcs(prop, "rna_LinkAppendContextItem_link_info_get", nullptr, nullptr);
prop = RNA_def_property(srna, "linked_appended_id", PROP_POINTER, PROP_NONE);

The linked_appended_* prefix reads poorly to me. We could just call this id ? (it looks to be the primary ID which would be referenced), other ID's can be clarified with longer names.

The `linked_appended_*` prefix reads poorly to me. We could just call this `id` ? (it looks to be the primary ID which would be referenced), other ID's can be clarified with longer names.
mont29 marked this conversation as resolved
@ -0,0 +438,4 @@
"only exposed as read-only data for the pre/post linking handlers");
RNA_define_verify_sdna(false); /* not in sdna */

Instead of exposing all of these in one collection, we could expose them by type, similar to Main & library linking/appending API's, e.g. data.scenes, data.objects ... etc.

The advantages would be:

  • Scripts that only want to operate on one data type (meshes, objects etc...) wouldn't have to filter by id_type.
  • Matches other areas of Blender.

Lookups by name on the collection would be possible, although I'm not sure if that's really useful in this context.

Instead of exposing all of these in one collection, we could expose them by type, similar to Main & library linking/appending API's, e.g. `data.scenes`, `data.objects` ... etc. The advantages would be: - Scripts that only want to operate on one data type (meshes, objects etc...) wouldn't have to filter by `id_type`. - Matches other areas of Blender. Lookups by name on the collection would be possible, although I'm not sure if that's really useful in this context.
Author
Owner

I don't think that that would be a good idea... It's moving too far away from internal data model to my liking.

Further more, there are cases were name lookup would still not be fully working (in case of missing IDs search and relocation, there can be several libraries processed at the same time, and therefore several ID of the same type and name in the context).

I don't think that that would be a good idea... It's moving too far away from internal data model to my liking. Further more, there are cases were name lookup would still not be fully working (in case of missing IDs search and relocation, there can be several libraries processed at the same time, and therefore several ID of the same type and name in the context).
mont29 marked this conversation as resolved
@ -0,0 +439,4 @@
RNA_define_verify_sdna(false); /* not in sdna */
prop = RNA_def_property(srna, "items_array", PROP_COLLECTION, PROP_NONE);

The name seems a bit off, it can't be items because of naming collisions with Python, but the array suffix is also a bit odd (as this is a collection).

Suggestions: datablocks, datablocks_pending ... link_append_items.


Even though datablocks is arguably not correct in that these aren't bpy.types.ID instances, we could consider it close enough as they represent data-blocks being loaded.

The name seems a bit off, it can't be `items` because of naming collisions with Python, but the `array` suffix is also a bit odd (as this is a collection). Suggestions: `datablocks`, `datablocks_pending` ... `link_append_items`. ---- Even though `datablocks` is arguably not _correct_ in that these aren't `bpy.types.ID` instances, we could consider it close enough as they represent data-blocks being loaded.
Author
Owner

I would rather not differentiate too much naming between internal code and exposed API if it can be avoided. And datablock is not used much in our API currently I believe? link_append_items is a bit redundant, but can go with that... Or we could also use elements instead of items?

I would rather not differentiate too much naming between internal code and exposed API if it can be avoided. And `datablock` is not used much in our API currently I believe? `link_append_items` is a bit redundant, but can go with that... Or we could also use `elements` instead of `items`?
mont29 marked this conversation as resolved
@ -0,0 +515,4 @@
"Instantiate collections as empties, instead of linking them into current view layer"},
{0, nullptr, 0, nullptr, nullptr},
};
prop = RNA_def_property(srna, "flags", PROP_ENUM, PROP_NONE);

In RNA we don't typically call these flags as that relates to bit-masks which don't make sense when called from Python, suggest options as we have for bpy.types.Operator & bpy.props.*.

In RNA we don't typically call these `flags` as that relates to bit-masks which don't make sense when called from Python, suggest `options` as we have for `bpy.types.Operator` & `bpy.props.*`.
mont29 marked this conversation as resolved
@ -0,0 +538,4 @@
};
prop = RNA_def_property(srna, "process_stage", PROP_ENUM, PROP_NONE);
RNA_def_property_enum_items(prop, link_append_process_stage_items);
RNA_def_property_flag(prop, PROP_ENUM_FLAG);

It looks like this shouldn't be treated as a flag based on it's use elsewhere.

It looks like this shouldn't be treated as a flag based on it's use elsewhere.
Author
Owner

Indeed, copy-paste error!

Indeed, copy-paste error!
mont29 marked this conversation as resolved
@ -99,6 +99,10 @@ static PyStructSequence_Field app_cb_info_fields[] = {
{"_extension_repos_sync", "on creating or synchronizing the active repository"},
{"_extension_repos_files_clear",
"remove files from the repository directory (uses as a string argument)"},
{"link_append_pre",

It'd be interesting to know if script authors would find it useful to separate: link & append.
It seems plausible a developer might only want to add a handler for the "append" case - if they intend to modify appended data for e.g. which doesn't make sense for library data.

It'd be interesting to know if script authors would find it useful to separate: link & append. It seems plausible a developer might only want to add a handler for the "append" case - if they intend to modify appended data for e.g. which doesn't make sense for library data.
Contributor

I would find that useful personally. But it would be lower on my priority list, so if it can take time I wouldnt mind if this lands in 4.3 without it.

I would find that useful personally. But it would be lower on my priority list, so if it can take time I wouldnt mind if this lands in 4.3 without it.
Author
Owner

It is fairly trivial to filter it by checking 'LINK' in link_append_context.flags (in current build, again will be renamed soon), so don't really see the benefit of adding several handlers here. Not to mention that more 'modes' already exist (append or reuse), and more are likely to be added soon-ish (embedded linking).

It is fairly trivial to filter it by checking `'LINK' in link_append_context.flags` (in current build, again will be renamed soon), so don't really see the benefit of adding several handlers here. Not to mention that more 'modes' already exist (append or reuse), and more are likely to be added soon-ish (embedded linking).
mont29 marked this conversation as resolved
Author
Owner

I tried testing this but I couldn't find my way unfortunately. I'm not too good at reading C++ code so I don't know how correctly I made my assumptions, maybe you or someone else can help me out.

Thanks for giving it a try. This will be much easier once the RNA structs are in main, and the python API doc has them documented indeed.

Trying to implement functionalities that I laid out in original design issue:

  • I need to access custom properties registered on the ID.

This should be possible in the post handler? The relevant IDs are all accessible there (currently in items_array[123].linked_append_array, but this will be renamed soon (see Campbells' review).

  • I need a way to access embedded IDs that come with appended object.

All indirectly linked/appended data should also be listed in the items_array data in the post handler. There is no direct information about relations between these IDs though, this you'll have to rebuild yourself if needed.

  • This is long shot, but would it be possible to override operator properties in pre handler?

Not for 4.3 (too risky at this stage), but I think it should be possible to make some parts of the LinkAppendContext data (and the related options) editable later, yes.

> I tried testing this but I couldn't find my way unfortunately. I'm not too good at reading C++ code so I don't know how correctly I made my assumptions, maybe you or someone else can help me out. Thanks for giving it a try. This will be much easier once the RNA structs are in main, and the python API doc has them documented indeed. > Trying to implement functionalities that I laid out in original design issue: > - I need to access custom properties registered on the ID. This should be possible in the `post` handler? The relevant IDs are all accessible there (currently in `items_array[123].linked_append_array`, but this will be renamed soon (see Campbells' review). > - I need a way to access embedded IDs that come with appended object. All indirectly linked/appended data should also be listed in the `items_array` data in the `post` handler. There is no direct information about relations between these IDs though, this you'll have to rebuild yourself if needed. > - This is long shot, but would it be possible to override operator properties in pre handler? Not for 4.3 (too risky at this stage), but I think it should be possible to make _some_ parts of the LinkAppendContext data (and the related options) editable later, yes.
Author
Owner

Documentation can note that "append" is an option for linking which makes the data local after linking (which is what happens internally). Without having to include LinkAppend in all of the names relating to this API... we could even apply this naming to C++ API's although that's out of scope for this PR.

I'd rather keep LinkAppend in struct names at least... I would not consider 'Append' as 'just an option' of linking, actual behavior is more complex than that (and is going to get even more complex in the future with things like embedded linking).

Other option would be to find a better generic terminology covering that whole area, but 'Import' is already taken for external formats...

> Documentation can note that "append" is an option for linking which makes the data local after linking (which is what happens internally). Without having to include `LinkAppend` in all of the names relating to this API... _we could even apply this naming to C++ API's although that's out of scope for this PR._ I'd rather keep `LinkAppend` in struct names at least... I would not consider 'Append' as 'just an option' of linking, actual behavior is more complex than that (and is going to get even more complex in the future with things like embedded linking). Other option would be to find a better generic terminology covering that whole area, but 'Import' is already taken for external formats...
Author
Owner

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR128279) when ready.
Bastien Montagne added 2 commits 2024-09-30 15:09:47 +02:00
Updates from review.
Some checks reported errors
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
43d24e6711
Author
Owner

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR128279) when ready.

Other option would be to find a better generic terminology covering that whole area, but 'Import' is already taken for external formats...

For more generic naming, including the term blend / blendfile makes the functionality unambiguous BlendImport for e.g.

> Other option would be to find a better generic terminology covering that whole area, but 'Import' is already taken for external formats... For more generic naming, including the term `blend` / `blendfile` makes the functionality unambiguous `BlendImport` for e.g.
Author
Owner

'BlendImport' looks and sounds nice actually!

'BlendImport' looks and sounds nice actually!
Contributor

@mont29 you're right I missed that I could use linked_appended_id (whick I think is renamed to just id now, right?)

I think it works fine for my purposes then. One thing I would like to clarify is that item.id.type would return type of that ID (like Mesh, Curve, Light for object, or ShaderTexImage for node) while item.id_type would return which ID type it is (Object, Mesh, ShaderTree, etc) right?


EDIT: One question I have is if it is possible to differentiate "main" ID being appended from rest that just come with it. For example if user chooses to append object, is it possible to get that object separately from its material, mesh, nodetrees and etc?

@mont29 you're right I missed that I could use `linked_appended_id` (whick I think is renamed to just `id` now, right?) I think it works fine for my purposes then. One thing I would like to clarify is that `item.id.type` would return type of that ID (like Mesh, Curve, Light for object, or ShaderTexImage for node) while `item.id_type` would return which ID type it is (Object, Mesh, ShaderTree, etc) right? --- EDIT: One question I have is if it is possible to differentiate "main" ID being appended from rest that just come with it. For example if user chooses to append object, is it possible to get that object separately from its material, mesh, nodetrees and etc?
Bastien Montagne added 1 commit 2024-09-30 15:45:04 +02:00
Further updates from review.
All checks were successful
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
723e93a9cf
Author
Owner

@mont29 you're right I missed that I could use linked_appended_id (which I think is renamed to just id now, right?)

Correct

I think it works fine for my purposes then. One thing I would like to clarify is that item.id.type would return type of that ID (like Mesh, Curve, Light for object, or ShaderTexImage for node) while item.id_type would return which ID type it is (Object, Mesh, ShaderTree, etc) right?

Yes, the (just renamed) BlendImportContextItem.id_type will have exactly the same meaning as existing ID.id_type property.

EDIT: One question I have is if it is possible to differentiate "main" ID being appended from rest that just come with it. For example if user chooses to append object, is it possible to get that object separately from its material, mesh, nodetrees and etc?

Each BlendImportContextItem has a import_info enum property, in post handler, indirectly imported items will be tagged with 'INDIRECT_USAGE'.

> @mont29 you're right I missed that I could use `linked_appended_id` (which I think is renamed to just `id` now, right?) Correct > I think it works fine for my purposes then. One thing I would like to clarify is that `item.id.type` would return type of that ID (like Mesh, Curve, Light for object, or ShaderTexImage for node) while `item.id_type` would return which ID type it is (Object, Mesh, ShaderTree, etc) right? Yes, the (just renamed) `BlendImportContextItem.id_type` will have exactly the same meaning as existing [`ID.id_type`](https://docs.blender.org/api/4.3/bpy.types.ID.html#bpy.types.ID.id_type) property. > EDIT: One question I have is if it is possible to differentiate "main" ID being appended from rest that just come with it. For example if user chooses to append object, is it possible to get that object separately from its material, mesh, nodetrees and etc? Each `BlendImportContextItem` has a `import_info` enum property, in `post` handler, indirectly imported items will be tagged with `'INDIRECT_USAGE'`.
Author
Owner

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR128279) when ready.
Bastien Montagne added 2 commits 2024-10-01 12:41:39 +02:00
Contributor

Everything works well for my purposes. I'm liking naming changes too. Thanks everyone who worked on this

Everything works well for my purposes. I'm liking naming changes too. Thanks everyone who worked on this
Campbell Barton reviewed 2024-10-02 06:23:42 +02:00
@ -0,0 +440,4 @@
RNA_define_verify_sdna(false); /* not in sdna */
/* XXX Cannot use `items` here as this is a reserved Python dict method name. */
  • XXX is more for warnings, this isn't something to resolve or fix, so it could be NOTE: cannot use ....

  • elements seems OK but also a bit odd,

    Possible alternatives:

    • import_items
    • data_items
    • link_items
    • datablock_items
- `XXX` is more for warnings, this isn't something to resolve or fix, so it could be `NOTE: cannot use ...`. - `elements` seems OK but also a bit odd, Possible alternatives: - `import_items` - `data_items` - `link_items` - `datablock_items`
Author
Owner

I'm fine with either elements or import_items, both are somewhat weird but withing acceptable limits imho. No strong preference so will let you choose the one you prefer. ;)

I'm fine with either `elements` or `import_items`, both are somewhat weird but withing acceptable limits imho. No strong preference so will let you choose the one you prefer. ;)

Slight preference for import_items matches (keymap_items, enum_items ... filter_items_by_name etc).

Slight preference for `import_items` matches (`keymap_items`, `enum_items` ... `filter_items_by_name` etc).
Bastien Montagne added 1 commit 2024-10-02 10:28:43 +02:00
Bastien Montagne added 1 commit 2024-10-02 10:29:13 +02:00
updates from review.
All checks were successful
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
39a73b8ab7
Author
Owner

@blender-bot build

@blender-bot build
Campbell Barton reviewed 2024-10-02 10:31:00 +02:00
@ -0,0 +421,4 @@
RNA_def_property_srna(cprop, "BlendImportContextItems");
srna = RNA_def_struct(brna, "BlendImportContextItems", nullptr);
RNA_def_struct_ui_text(
srna, "Link Append Context Items", "Collection of link/append context items");

Should "Link Append" be renamed to "Import" here? (description mentions link/append).

One other instance of "Link Append" exists here too.

Should "Link Append" be renamed to "Import" here? (description mentions link/append). One other instance of "Link Append" exists here too.
Campbell Barton approved these changes 2024-10-02 10:31:07 +02:00
Bastien Montagne added 1 commit 2024-10-02 10:59:39 +02:00
Bastien Montagne added 1 commit 2024-10-02 16:06:59 +02:00
Merge branch 'blender-v4.3-release' into tmp-link-append-handlers
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
079d847597
Bastien Montagne changed target branch from main to blender-v4.3-release 2024-10-02 16:07:09 +02:00
Author
Owner

@blender-bot build

@blender-bot build
Bastien Montagne merged commit 76e7770bc9 into blender-v4.3-release 2024-10-02 16:44:50 +02:00
Bastien Montagne deleted branch tmp-link-append-handlers 2024-10-02 16:44:54 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#128279
No description provided.