- Amsterdam
-
Asset system (development lead), UI (developer & module coordindator), VR (initial development).
- Joined on
2013-12-12 -
-
Talked to Bastien, he rejects the idea of something like a ui_name field in IDTypeInfo for this purpose, because then the object callback would have to get the IDTypeInfo of the object data,…
I guess the need to store these at all is just a future-proofing thing?
They are stored in the asset metadata so this type information becomes available when loading asset representations,…
Bastien is quite against doing this on asset marking only, so let's do it on file save in ED_assets_pre_save().
As a note, I'd like to add this for assets as well, for when the user chooses to hide names in the asset-shelf for example.
Could the
get_obdata_uinamestuff be replaced with use of theIDTypeInfoofob->data?
We could have a const char *ui_name in there and assign that to the ID_UI_NAME_ value indeed.…
Think calling this value makes more sense. Same for the tags actually, but yeah, not worth bothering.
Use the same or a similar description as elsewhere. Here this is especially important, since this will be the description for the Python documentation of the type.
/*ensure_traits_fn*/ object_asset_ensure_traits, (the trailing comma ensures the closing } is put on the next line, which I find more visually pleasing and we usually do this.
Either remove this or actually implement the filtering in ED_asset_filter_matches_asset().
