The operator is actually used in the pose library Asset View (release/scripts/addons/pose_library/gui.py), to make a distinction between "immediately apply" and "interactively blend". Since it's actually in use, I think it's fien to keep around.

I don't think functionality like this should be in RNA. IMO it should be part of the asset system, so either stay here or even be part of BKE.

This should declare the enum type as return type, and not just int. If that's impossible, it should at least document this clearly.

The _to_enum_value suffix isn't the most descriptive either. Maybe _get_library_type?

Same issue as above with _from_enum_value and having int as the only indication of the enum type.

This is just return ELEM(notifier.action, NA_RENAME);

This is just:

return ELEM(notifier.data, ND_ASSET_LIST, ND_ASSET_LIST_READING, ND_ASSET_LIST_PREVIEW) ||
  ELEM(notifier.action, NA_ADDED, NA_REMOVED, NA_EDITED);

I hope Clang-Format would spread that over multiple lines in a readable way, though (like above). If not, I prefer the current code.

Shouldn't this handle all cases where library_reference.type >= ASSET_LIBRARY_CUSTOM? If so, I think it's cleaner to have some function is_custom_library(library_reference) somwhere, such that the concept of "anything over ASSET_LIBRARY_CUSTOM is a custom library" doesn't have to be copied all over the place. Come to think of it, I think such a function is a good idea anyway ;-)

I think that sentence misses a "++" somewhere.

In any case, I would just remove the C API if it's not in use. It's quite a bit of code, and if it sits unused it'll rot.

Does this work in the Asset View as well as the Asset Browser?

That could work, but only if the "activate operator" is executed on activation, and invoked on drag. This is currently not the case (you can test by changing activate_operator="poselib.apply_pose_asset" → "poselib.blend_pose_asset" in VIEW3D_PT_pose_library).

File LGTM

Would that be something like ED_asset_list.hh?

These changes come from rB063c248cb706, and from the look of it, the non-asset-specific stuff could go directly into master AFAIC.

Maybe then also change const bool to bool? bool is passed by value, so const in the declaration has no meaning.

File LGTM

Why is stdio.h needed here? I don't see it being required by the other changes in the file.

Does this describe the workings of the function? Or is it a note that should be marked with a TODO?

Why are these functions marked extern? According to these two random search hits (one, two) all functions are implicitly marked as extern, and adding the keyword explicitly has no meaning.

This all sounds rather dodgy. But, at least the dodgyness has been moved from somewhere-in-the-middle-of-some-function to a function by itself, and described in a appropriately-dodgy way, so I guess it's a step forward!

I'd just add a return; in the if-block, remove the else, and unindent the rest of the function.

const?

LGTM

File LGTM

File LGTM

File LGTM

File LGTM except where noted

This should get a comment to explain what it means.

Same issue as earlier; library_a->type > ASSET_LIBRARY_CUSTOM is also an indication it's a custom library.

If this is not the case here, but is the case in other uses of exactly the same enum values, this should be redesigned.

This should be abstracted away into some filelist_entry_has_uuid(entry, uuid) function.

This still doesn't make sense to me. It really should have an explanation as to why it's ok to leave r_uuid[1..3] untouched.

What guarantees that some_ID->session_uuid != FILE_UUID_UNSET?

Couldn't this also mean that there are no file list entries, and thus that the caching of the previews is actually trivially done?

This really belongs in its own function.

The "uuid" naming is getting messed up. So far these are all used interchangably:

FileListIntern:            char[16]
filelist_uuid_from_id():   uint32_t[4]
ID:                        unsigned int
filelist_uuid_from_uint(): uint32_t[4]   but only the first element

This also relates to D7007: Add a session-wise uuid integer to IDs. introducing something that's not a UUID but still calling it one. I've raised an issue about this in the #core-module channel on Blender Chat, as this goes beyond the scope of this patch.

const

File LGTM

This looks like it should be a separate function filelist_file_find(sfile->files, params) (see "G14: Feature Envy" in Clean Code).

These two structs don't seem to be required (no other changes to this file), so I'll remove them.

File LGTM

File LGTM

File LGTM except where noted.

Some of the added includes are no longer necessary, I'll remove them.

LGTM

File LGTM except where noted.

File LGTM

This is nasty, as it'll actually be stored in a uint32_t. Either use 4294967295L or ((uint32_t)-1).

File LGTM

File LGTM

File LGTM

File LGTM

"this version" is a bit ambiguous. Do you mean "this struct"?

Document why it should go after spaces.

File LGTM except where noted

Add a comma after not EnumPropertyItem, otherwise strictly speaking the sentence means pretty much the opposite of what you intend it to mean.

File LGTM except where noted

Remove the comment, or add another comment that explains why it should be kept ;-)

Remove it, see what breaks?

Can't we return an instance and let the Python GC handle its destruction? Honest question, I don't know if this is possible with RNA.

File LGTM

Is this still necessary?

File LGTM

Same question as before as to valid library types & having a separate function for these kind of comparisons.

Same as before: delegate to different function; same for similar code below.

Why is this? Why not just pass the full list ID to Python?

I suspect these can all become const

File LGTM

File LGTM

There are three values here, but only one description. Which value does it map to? And what do the others mean?

File LGTM

File LGTM

File LGTM

File LGTM

meh, out of scope for this patch, and can always happen in some clean-up.

const

filelist_uuid_unset() only sets the first element of the UUID array, but memcmp() compares all elements. This is unacceptable, as it relies on undefined behaviour of the initialisation of arrays.