Related to #167 but not linked (yet?)

Should the value change based on changes in creator attributes?
Should be the label stored in scene?
Do we have any other use-case in mind?

Should the value change based on changes in creator attributes?

Yes, please.

Should be the label stored in scene?

I'm fine with the creator being able to compute/define it dynamically.

Do we have any other use-case in mind?

It may be more than 'label' but just showing metadata like start frame, end frame, colorspace or whatever would be nice to 'promote' and visually show on the instance for easy debugging. However, once we go down that route I feel we may first need some 'redesign' to pinpoint WHAT makes sense in design?

I'm fine with the creator being able to compute/define it dynamically.

I can't do it dynamic if it would be based on transient data (I don't can't listen to changes there). So I guess it would be some additional key on instance data? Or it can be specific method on instance (that would store it to transient data, but also trigger event).

It may be more than 'label' but just showing metadata like start frame, end frame, colorspace or whatever would be nice to 'promote' and visually show on the instance for easy debugging. However, once we go down that route I feel we may first need some 'redesign' to pinpoint WHAT makes sense in design?

So it might be more than one line of information? Wouldn't that make the UI more "messy"?

This is how UI showed it in draft PR

I can't do it dynamic if it would be based on transient data (I don't can't listen to changes there). So I guess it would be some additional key on instance data? Or it can be specific method on instance (that would store it to transient data, but also trigger event).

I meant that it could be up to the creator to just set attributes that are related to the label. I've tested this recently and it already works - I can set any custom label on a CreatedInstance and update that dynamically as a response from a registered callback.

For example I had this:

        # Add the folder path to the instance name as a label
        # if it does not match the current context to identify
        # it is publishing elsewhere. Especially useful with multi-shot
        # workflows
        folder_path = instance.get("folderPath", "")
        if folder_path != self.create_context.get_current_folder_path():
            product_name = instance.get("productName", "")
            instance["label"] = f"{product_name} ({folder_path})"

    def register_callbacks(self):
        """Register Houdini specific callbacks for context creation."""
        self.create_context.add_value_changed_callback(
            self._on_value_changed
        )

    def _on_value_changed(self, event):
        """Update the label of the instance on folder path changes"""
        for change in event.data["changes"]:
            if not change.get("instance"):
                continue

            instance: CreatedInstance = change["instance"]
            if instance.creator_identifier != self.identifier:
                continue

            if "folderPath" not in change["changes"]:
                continue
            self.read_custom_data(instance)

And the of course the creator's create() and collect_instances() also set the label initially.
Which looked like:

I figured this issue initially was by making the cards more useful by default to e.g. always display things like frame metadata, folder, etc. so that one could easily spot the most common 'uniqueness'. Which I'd expect indeed be more of a design question then just textual update on the label?

Just wanted to mention this issue: ynput/ayon-houdini#155

It may overlap (or even be solved) by UX changes from this issue - if e.g. the instance cards could help identify which scene node/instance it would be.

So just referencing it as a potential production use case.