Last Friday, we got rez env --no-local integrated into the GUI and said to make this week about styling. But over the weekend, I noticed a few important features was missing that I'll have a look at in the next few days.
Rez is able to add a package to an existing resolve dynamically, which means you could potentially add additional overrides to a given project/application combo. Like a maya_legacy_viewport package, to gain access to Maya's Viewport 1.0. Or a grewishka for additions related to an.
Spontaneously, I wanted to add an item to the bottom of the packages list that the user could type into. On completing input, the package would get patched into the list. But there are a few issues with that.
- Length The list can be long, which means scrolling to reach the editable item. On re-resolve, we would then either need to keep track of the scroll position or let the user scroll back down to re-edit or add a new package
- Order The order of packages isn't easily pre-determined. They're ordered by how they are resolved (unless sorting is enabled by clicking the headers). That means that although you would expect patched packages to appear at the bottom, they may very well intermix and sit just about anywhere in the list.
- Serialisation We'll likely want to store patches relative a project/application combo, for example when the user exits and restarts the application, or simply between switching applications. If they item is intermixed with non-patched packages, we would need to implement a rather complex method of extracting patch changes from the rest, and re-apply it later.
- Version override A non-patched package can have its version overridden, by double-clicking on its version. But how should that work with patched packages? Ideally, you would edit your patch to specify a different version.
So instead I went for a more robust approach.
If you had assets as packages, this is where you'd be able to specify those as well. Patches are applied as a layer on-top of the primary resolve, and remain cross-application and cross-project. They are meant primarily as a development utility, rather than an artist tool. If a developer wanted an artist to gain access to a particular patch, they would simply embed this into the project requirements.
Establish support for a theme, along with editable CSS for rapid prototyping.