Having a look at theming today.
But first, during testing at the office we spotted a few bugs that I've ironed out today.
- Resetting the Info tab "Tool" selection doesn't work
- Patching a BrokenContext doesn't work
- Localization was assumed, launching without it threw an exception
-
REZ_PACKAGES_PATHoverrides the global config, as it should, however we probably want to let the user know that's the case. It's not critical, and solvable by the developer. Logged an issue here
Next, one of the main hurdles in designing a GUI is iterating. Typically, you..
- Launch the app
- Find something to edit
- Quit
- Edit the appropriate identifier in CSS
- Save
- Goto 1
And that's a pain. The Web browser solved this issue by enabling changes to CSS happen interactively in the GUI. That's what I want for Allzpark.
2h later
And there we go.
- mottosso/allzpark#13
- Every widget has a unique name and can get styled
- User CSS is added on-top of "default" css
- User CSS is saved and restored between runs
- Interactive updates via
CTRL+Sor hitting the Apply button - Syntax highlighter for a native feel
Next was a change of plan. Given I've got about 2 weeks left, there are more important things than cosmetics to take care of, one of which is an editable environment.
Usecase
- Enable the artist to flick a switch on various features, e.g. provided by the developer, by setting some environment variable.
This this, like with patching an environment, I initially thought of making the tree-view itself editable, but like with patching, it complicates drawing and storing of changes. So instead, the more robust approach is to give the user an editable text field, similar to the CSS Editor above, which is appended on-top of any environment made by Rez.
The danger in doing this is that, like with the brute-force editing of package versions, Rez isn't aware of its environment changing. Which means you can break things and not become aware of it.
Ideally, these kinds of overrides would happen via additional "override packages". A package containing just a few variables, like MAYA_LEGACY_VIEWPORT=1 that the user can append to their patch field in the GUI. That way, it is still within the control of the developer to set requirements on this package and in so doing also what makes the package conflict with a particular combination of packages. For example, maybe there was another package that doesn't support Maya's legacy viewport and would break if it got set.
However, the barrier in doing that is higher, so both options should (probably) be made available to the artist and developer, which is what I'll implement next.
2h later
Ok, let's have a look.
- mottosso/allzpark#9
- Freeform text editor, with
KEY=VALUEsyntax - Variables separated by newline
- Values can be any value, but keys must fulfill the regex
^[A-Za-z0-9\._]+$ - User environment used as a starting point for packages environment, which means a user cannot break a context, but can only append to a resolved environment. The downside is, a user cannot edit a variable also edited by a package.
Tomorrow I'll implement visual feedback on whether there is a newer package available or the artist to choose from and take a slight detour into Pyblish-land to implement functionality currently missing for Studio Anima; I also expect production testing to reveal additional feature requests and possible bugs to iron out.