This could become a UIList, but I kept it consistent to the "Excluded Paths" UI for the autorun scripts.

This is for per repository data, like repository-level catalogs (e.g. to group together poses as a "library").
WITH_ASSET_REPO_INFO should be disabled for now and relating structs be disabled for SDNA.

(The current design for this is to write a single asset repository data block to a file as a new global struct, so that it can be read without reading the entire file. Similar to REND. The meta-data of a repository is then the union of all these global repository data blocks from all the .blends. --- Obviously this design needs discussion.)

Comment needs updating.

Should maybe set (or ensure?) a real user.

I don't think we should do this, too expensive for a poll(). Was just experimenting with it.
I'd love to have grayed out buttons and a disabled-hint if needed in context menus based on selection, rather than always having the operators there and having them fail.

This is currently not working. T82664

Would be good to have done before a release, but can be a bcon2 task.

This is a showstopper for me, I don't want to cause thread-races.
Generating the file-list from Main should be quite fast, we could just disable threading or block for this.

This is a bit messy, would like to clean it up.

Outdated comment, should remove it.

There's not much point in this, should always use the ID's preview.

I'm not sure if we should keep these properties here. They could just be added as custom properties if needed. At least the description and author fields.

Not needed anymore.

We use Metadata without the hyphen in other places in the UI like image editor and sequencer.

We could consider having this simply as a text field separated by spaces, since it's faster to add or copy-paste a bunch of tags, and commonly done that way on the web.

That can be done regardless of how the data is stored internally though.

The lack of multiline textbox for this and description is unfortunate, would be good to support that at some point in the future.

Perhaps put this panel at the top or bottom, it looks a bit off to me to have this between other panels that all look similar.

I'd suggest to switch the order and put name first.

Suggest to align this on the right side.

Are we sure this pointer remains valid, that the ID or preview does not get deleted?

In general, what is the mechanism to ensure these entries stay in sync with the main database?

I suggest to name this AssetTag or MetaDataTag. I'm not sure why "custom" is needed, aren't all tags custom?

Personally would name this AssetMetaData, since "data" doesn't mean much.

Agree, should be removed.

I think it makes sense for description and tags to be built-in. For everything else I guess we use ID properties presented in a nice UI?

Something like custom properties, but a bit nicer and tuned to this use case, and eventually some options to add standard metadata types like author or license.

I'm not sure the struct needs to be this specific. Would it make sense to have a single struct that store all asset browser specific settings, which includes this ID?

I'm not sure we should have author as a native property, but if we do then this description seems wrong to me. It's the creator of the asset, responsibility is something else.

The naming here is getting a bit confusing to me.

Maybe it helps to rename existing functions and enum items to "local ID", and then use ID to refer to cases where it can be an ID from any source? Ideally the distinction between the two can be mostly abstracted for drop code.

I just tested this and it isn't true anymore, it also changed with my adjustments to the way this is exposed in the "non asset file browser" a few months ago. (Other uses of .popover( in this file).

Also, looks like the recursions property isn't initialized properly:

This pointer was already used above, right? So no need for the "safe" part here, this function assumes it.

Typo: and -> an

Hmm, if I try this, and don't manually set the icon, I get this:

The UI here is kind of a dummy one and needs to be done properly. That's part of T82680.

I personally prefer the UIList layout for now. Communicates much better that you're actually adding separate items/tags, not just a string.
For me, a dedicated tag editing widget/template is part of the usability improvements milestone, including multiline support (see D7496). It could support copy/paste and automatically display separate tags as you enter or paste commas.

I generally prefer MEM_SAFE_FREE(), not just because of the null-check but also because it nulls the pointer. Avoids nasty mistakes.
But actually I'll change this to a slightly different pattern.

It's unsafe and I plan to address this, see T82886: Crash on undo while showing "Current File" repository. Should definitely be done before the merge.
Also created T83242: Ensure "Current File" repository stays in sync with main data-base, although it's kinda the same issue really.

It shouldn't store a reference to ID data like this (same for the asset-data). At least not without extra sanity checks. The preview will later be copied into an image buffer, but may break meanwhile because of the threading.

I already added FileListInternEntry.id_uuid and FileList.id_map, which we could use to sanity check the references before access.

We also store this in the file-list. That way we can check if the file-list needs refreshing. I generally like small, focused structs/classes, although in this case it also affects SDNA of course.

How would you imagine the single struct to look like, what would it contain?

Yeah agreed.
And once the drag/drop rewrite is in eventually, the distinction should indeed be abstracted away.

Ah, I see the issue. Before my recent change to these popovers in the file browser I noticed that this gives the popover button some suboptimal tooltips, but that's a small issue. I can revisit this when the UI is further along I suppose : )

Okay, thanks. I wasn't sure what was changing in the future and what wasn't.

I didn't expect we'd make the custom properties editable from the UI, but guess it's reasonable. If you think it's needed I will create a task for it.
Would you agree this is lower priority for now, something we can wait for until 2.93 even?

Removed the author field btw.

Changed the naming to be more clear and used "local ID".
For the last function I chose WM_drag_get_local_ID_or_import_from_asset(), think it's good to be clear.