I think the limitations are fine for our current use case, by the way. Maybe they should be documented in the code, though, so that it's clearer what the limitations are, and in which area of the code they could be addressed? Not vital for acceptance of this patch IMO.

Updated the patch to use an argument to Layout.template_asset_view.

In D10843#278139, @Julian Eisel (Severin) wrote:

Thanks for working on this!

• We could use a struct for storing preview preview transformation to avoid having to add more arguments in the future.

Don't think this is needed. I don't see much reason for more advanced transformations.

• Currently no popup support, no support in the file browser.

What do you mean with popup support?

Preview icons can show in regions generated by an enum popop - any template_preview for example.

File Browser support is the most important thing right now.

Perhaps best handle this in chat, I need a use-case to test this.

• We could handle this at a different level (flip the preview data after loading for example).

Managing the preview data is already problematic: Threaded rendering + undo/redo (they are ID data), shared data-structures but partially separate code paths with .py preview icons, deferred loading from OS thumbnail cache, complex ownership... Generally I'd prefer not to add more complexity.

Yep, it seems unnecessarily complicated in that case.

In D10843#284693, @Sybren A. Stüvel (sybren) wrote:

This ought to use the symbols from eIconFlip.

This note hasn't been handled, or even replied to.

Accidentally left the reply unsubmitted, done now.

@Sybren A. Stüvel (sybren) where there any outstanding issues you wanted to check over?

Otherwise I don't think the minor issue with .arcconfig requires an extra review iteration. It can be removed from the final commit easily enough.

To test flipping in the file-selector, this script sets the value

I've tried it with the following code in an Asset Browser panel, and that works as well:

def draw(self, context: Context) -> None:
    layout = self.layout
    wm = context.window_manager
    if wm.poselib_flipped:
        preview_flip = {'X'}
    else:
        preview_flip = set()
    context.space_data.params.preview_flip = preview_flip

Is this the best way to deal with this? Or would you expect to have some update-callback on the window_manager.poselib_flipped property that handles this?

How would you handle this in the UIList asset view template?

In D10843#286449, @Sybren A. Stüvel (sybren) wrote:

To test flipping in the file-selector, this script sets the value

I've tried it with the following code in an Asset Browser panel, and that works as well:

def draw(self, context: Context) -> None:
    layout = self.layout
    wm = context.window_manager
    if wm.poselib_flipped:
        preview_flip = {'X'}
    else:
        preview_flip = set()
    context.space_data.params.preview_flip = preview_flip

Is this the best way to deal with this? Or would you expect to have some update-callback on the window_manager.poselib_flipped property that handles this?

As far as I know yes. And I'm not satisfied with this.

It has the down-side that if we somehow save this setting and the file selector is used in some other context, the user could have inexplicably flipped previews.

A better solution likely involves customizable properties that control settings like this, something the code that uses the file selector can control.

How would you handle this in the UIList asset view template?

Unless there is some other UIList usage for assets: template_asset_view takes a boolean argument for this, there was an example panel & list in earlier versions of this patch - for testing.

I'd expect the flag to be runtime only data (it isn't in this current patch). It is just a drawing-flag really.