I have a plugin that I’ve written that copies data from a folder into a shot/step.
Each item is collected in a collector and the context is identified by parsing the file name.
However sometimes the artist needs to change the context in order to copy data to a different shot (using the context widget on the item). The plugin uses settings to display to the user the output path and other items. These are currently built at accept time and added to the settings (as that’s the only place I can find that has both the item and settings).
I have two main issues:
The settings need to be updated when the context is changed (different fields for templates, affects versioning, etc), is there a hook method that runs when the context changes?
I need to update the UI to show the new settings.
My current solution is as follows (but has a few issues):
Keep track of what context was used for generating the settings (in a setting). At validation time if current context doesn’t match the one in the settings, I rebuild them and fail the validation (to alert the user that there has been changes to the settings).
It would be great to be able to update these values before hitting validation
We’ve had some inconsistencies with settings UI not updating when the settings update during validation time (the artist would need to open another settings window and go back, forcing the update from settings).
Hmmm Yeah I see your point. I think your work around makes sense, but it is a workaround it seems like we should handle this better.
Really (although it doesn’t) when a item’s context changes it should reload all the plugins under it, since if the context is different it might load plugin settings from a different environment, and I wonder if that was avoided so that plugin settings weren’t wiped out when the user changed the item context.
Ya it’s tricky to handle the context update conceptually as you may need to change some settings but you don’t want to change things that the artist has manually set. We try to compromise by making sure that the artist is aware that we reset everything.
Maybe it would be good to have a context_changed(settings, item) method on the plugin that you could implement to do any adjustments that you needed for your specific plugin.
If we had this and the UI was updated with any new settings then at least the developer could decided how he wanted to handle the settings updates based on the new context.
Might be worth passing the new and old contexts into the method too.
I talked about this post at length with the Toolkit engineering team today. You bring up a great point, but exactly how we’d choose to deal with it is a little up in the air. As you know, at the moment, we don’t re-evaluate the UI after an item has changed context, though it seems like we certainly should.
We have an existing feature request for getting the plugin settings from an item’s current context. This means that when you change context for a plugin, the settings also change. I think that this feature, provided the UI changed to reflect it, would get you much of the way there. But we’ve hesitated on moving forward with it, because it could be destructive: by changing context, you’d lose all your settings, which could include screenshots, descriptions, etc. (This echoes what Phil mentioned above.)
I think your context_changed() method idea is an interesting one – it would certainly empower plugin developers to deal with this situation nicely.
There are some good feature requests here, so I’ve shared this whole conversation with the product team; we’ll keep you posted if there’s any update!
