Sorry for all the commit spamming, but got the test to pass now.

Nice work !
I see you mentioned about LayerSets was not a good fit for being a container in the comment of #516, but what about group ? Current container is a single layer object right ? Will it able to load another PSD file while preserving layers ?

but what about group ?

What do you mean with group?
A LayerSet is a group in the javascript.

Current container is a single layer object right ?

Yeah, currently a container is a single layer, but you could essentially containerise multiple layers with the same metadata.

Will it able to load another PSD file while preserving layers ?

When using smart objects, the layers from a PSD gets flattened. Unless I'm missing a workflow?
Smart objects are the only way that I know of to reference media into Photoshop. There might be a method similar to our Nuke nodes referencing, but think that it'll be very complicated.

A LayerSet is a group in the javascript.

Ah ! Did not know that, thought they were different things. Thanks !

but you could essentially containerise multiple layers with the same metadata.

If that's the case, could containerise accept a list of layers instead of single layer ?

When using smart objects, the layers from a PSD gets flattened.

So the COMObject which should be passed into containerise could be a smart object ?

Unless I'm missing a workflow?

No no, I was just imaging what would I have to do to referencing another PSD file or other kind of subsets that may have multiple images or layers.

Unless I'm missing a workflow?

No no, I was just imaging what would I have to do to referencing another PSD file or other kind of subsets that may have multiple images or layers.

But if publishing or loading that kind of subset in Photoshop would make things too complicated from actual production needs, then I can ignore that. :)

If that's the case, could containerise accept a list of layers instead of single layer ?

Sure, that is possible. Though I thought for the sake of simplicity of the function, have a single layer as argument would be better? Can always containerise multiple times.
Or is your argument that all other hosts (except Fusion) containerises multiple objects?

So the COMObject which should be passed into containerise could be a smart object ?

Yeah, could be any layer or LayerSet for that matter. In Photoshop layers are LayerSet and ArtLayer which translates to group and layer in the UI.
So if you figure out a way of read/loading multiple layers, you could just containerise a LayerSet (group) with all the layers in.

If that's the case, could containerise accept a list of layers instead of single layer ?

Sure, that is possible. Though I thought for the sake of simplicity ... Or is your argument that all other hosts (except Fusion) containerises multiple objects?

After a good thought, I think it's not necessary for Photoshop. Plus, artist can only find stuff from that layer stack UI, so yeah, it's a good idea to keep things as simple as possible. 👍

So the COMObject which should be passed into containerise could be a smart object ?

Yeah, could be any layer or LayerSet for that matter.

Nice !

This PR is waiting on #523 to be merged.

The problem with #523 is still this particular comment. That should need to be tested and made sure that Blender will continue to work.

With 98503a6, this PR is ready to be merged.
Let me know what you think.

The #527 actually has a generic server which we could use for all Adobe products.

Lets leave this PR open for now, and I might rework this PR.

@tokejepsen You mentioned potentially reworking this PR. Should we merge this as is and open an issue? Should we close this? I noticed Pype merged something like this. So this is usable? If so, is there any documentation? :)

The Pype team have been using this in production, so there may be a couple of bugs from them. Otherwise, yeah, we could merge this.

The Pype team is also working on a second iteration using websocket and native javascript in PS for cross platform compatibility, so the question is whether we wanna wait for that.

@mkolar and @iLLiCiTiT can update about the production testing and second iteration.

This PR has been superseded by the Pype, so it better for the code to come from there.