Re-implement Nuke imprint

[davidlatwe]

This PR is the first step of refactoring #438, for resolving imprint which functionality was a bit rigid.

What's changed

• Re-implemented lib.imprint
• Changed following functions to adopt new lib.imprint:
  • lib.set_avalon_knob_data
  • lib.add_publish_knob
  • pipeline.Creator
• Add back lib.get_avalon_knob_data from Nuke: storing attributes in separated knobs with backward compatibility #438

About lib.imprint

Nuke has three categories of knobs, data-stored knob, layout knob and complex data knob, but let's put complex data knob aside for now.

On data-stored knob, imprint will create knob which fits to regular data types, like bool, int, float, str, list. For dict, it will become a group of knobs, or a group of tabs.

For example:

# Creating two group of knobs
node = nuke.createNode("NoOp")
data = {
    "group1": {
        "group1.var1": 5,
        "group1.var2": "hello",
        "group1.var3": ["a", "b"],
    },
    "group2": {
        "group2.var1": 6,
        "group2.var2": "world",
        "group2.var3": ["o", "p"],
    },
}
lib.imprint(node, data, tab="User")

Which you will get

And this:

data = {
    "tabGroup": {
        "tab1": {"count": 5},
        "tab2": {"isGood": True},
        "tab3": {"direction": ["Left", "Right"]},
    },
}
node = nuke.createNode("NoOp")
lib.imprint(node, data, tab="User")

Will looks like this

And if you wish to use other kind of knobs which is not mapped in lib.create_knob, you could use lib.Knobby, for example:

data = {
    # Using tuple as key for manual nice naming
    ("my_knob", "Nice Knob"): lib.Knobby("Text_Knob", "Non-editable text"),
    ("divider", ""): lib.Knobby("Text_Knob", ""),
    "MyFilePath": lib.Knobby("File_Knob", "/file/path"),
}
node = nuke.createNode("NoOp")
lib.imprint(node, data, tab="User")

And you have a file path knob

---

Hope this PR make sense to you, please let me know what you think. ☺️

[BigRoy]

Could this be turned into

node = next((n for n in nodes if n["name"].value() in self.name), None)`

Also, the fallback to nuke.allNodes() at the top, would you ever want that to accidentally happen? Seems like that could cause crazy things at some point. You might, I'm just not sure what the intended workflow is.

And, line 161 will cause error on nothing selected None[0]. Maybe better to report a decent error message like "Select X or Y"?

[davidlatwe]

I think this has been taken cared by some of the commits in #438 , a bit hard to tell which's which, but from the full changes could see that's been improved.

Should be shipped in next PR :P

[jakubjezek001]

yes this has been fixed additionally in #438

[tokejepsen]

Nice compacting of the knob logic @davidlatwe !

[mkolar]

I like it. Certainly cleaner

[davidlatwe]

New minor changes

First two commits (7079c14, 9229fec) were the fixes to complete this PR. The rest were minor improvements.

It's good to be merged now, but I'll be out for travel starting tomorrow till next Thursday so if no other objections, merging this next weekend !

[davidlatwe]

Sorry, just spotted that updating container will create duplicated knobs if existed, commit dc82024 fixed that. And one more change is if given an invalid container node, TypeError will raised. (7715ebd)

That's it !!

[jakubjezek001]

Would it be possible to turn this into prefix=["avalon:", "ak:"] for backward compatibility with already running productions? it was previously prefix="ak:"

[davidlatwe]

Ah, okay, but I won't put mutable value as arg's default value, I might hard code it in the for loop below :)

Speaking of which, was there any reason for applying prefix on knobs ?
Would it be okay if we not using prefix in future (with backward compatibility of course) ?

[jakubjezek001]

Would it be okay if we not using prefix in future (with backward compatibility of course) ?

If you found the efficient way to filter only avalon attributes from all knobs then yes. The reason was to separate only avalon metadata attributes, but didn't see other way to do it ;)

[davidlatwe]

I have found a way to list out all user-defined knobs in any given node, just like other host implementations (lib.read). But noted that user-defined layout knobs like tab or group will be listed too.

Here's the gist for trying:
https://gist.github.com/davidlatwe/519528bb01b4ff816389464ec2709e97

Maybe we could work without prefixing knob name if this works ?
Anyway, I'll try resolving this in another PR, this PR will be merged as is for now. ☺️

[tokejepsen]

Interesting solution!
Listing user defined knobs would definitely be useful.

[davidlatwe]

@jezscha I end up implementing the backward compatibility in a new method lib.read, instead of changing lib.get_avalon_knob_data. Please let me know how you think of this, it's in PR #476 😃

[jakubjezek001]

@davidlatwe this PR is awesome! Thanks for help ;)