Save layouts with script #50
Comments
ghost
assigned 
|
When we do this, it'll be very nice to also store the NodeGraph zoom settings in the layout. |
|
There have been several requests at IE that pinned state (including which nodes) are included with the saved layout and restored accordingly. As discussed on #19, we'd like to add this to the thought process (even if we later reject it) when implementing saved layouts. Just pasting some thoughts from @johnhaddon from an internal IE ticket:
That was a while back though, so maybe a few things have changed and/or clarified since then. |
|
@andrewkaufman Are you able to elaborate on the workflows where saving the layout in a script is most useful? Be good to better understand the use cases. From my research this end, most of the folks in London would turn this off 95% of the time... |
I gathered some feedback today from 3 (not-randomly-selected) individuals from departments who have been vocal about this feature in the past. When asked if they still want saved script layouts & saved pinning, even once we have the upcoming Gaffer 0.54 features (eg drap/drop/detach, restored window/panel sizes, serialized numeric bookmarks).
When asked about opening someone else's script to (a) help them debug something or (b) takeover the lookdev/shot, would you want their layout and pinning to come up or yours?
|
|
Thanks @andrewkaufman, thats really helpful. Appreciate you taking the time to gather the details. From a first read, it does sound like pinning is the primary motivator on the whole, rather than just editor layouts per-se. So if you saved a layout and not the pinning state, it'd be of limited value. We shall mull a a good solution for this. |
andrewkaufman
added
ui
|
I've been reluctant to implement this one, but I haven't done a very good job of articulating why. My main concern stems from the "open up the exact same way we left it" comment above. Each editor has a lot of state that needs to be serialised before we can open up the exact same way and we currently don't have a good way of serialising any of it. I know we've said "layout and pinning" at least once above, but I think that's just the thin end of a very long wedge. And I don't want to get into a situation where we keep extending some nasty ad-hoc serialisation format with more and more bits and pieces, and never take the time to step back and refactor to do it cleanly. I think the right way to do this is to use plugs to specify editor state, either by having Editor derive from Node, or for each editor to have an associated settings node. We're part way there with the So, can we say that this ticket is purely "layouts and pinning" and any other request for additional state will have to be bundled up into a much larger piece of work involving the "settings as plugs" approach? |
I'm comfortable limiting the scope to layouts and pinning for now. Its a pity we'd lose your suggestion of saving graph zoom (and I assume dive) level, but I think its a worthwhile sacrifice in order to satisfy a long standing user request. |
|
Quic q here - how often are people wanting to save a specific layout in a script vs most scripts having the same layout (ie panel arrangement) just pinned to specific nodes/etc? |
|
This is by no means conclusive, but using the same 3 users I canvased before and going off what they told me back then:
I suspect that reflects the type of work done in those departments most often:
|
|
Thanks Andrew, that’s really helpful. Appreciate the time in research. |
This holds all the Tools connected to the View, and provides more principled lifetime management between Views and Tools (formerly, `Tool::m_view` could be invalid if the View dies first). Parenting tools into the View is also a step towards the full serialisation of layout state discussed in GafferHQ#50. The eventual idea is that if the UI is a hierarchy of GraphComponents, then it can be serialised using the same mechanism used for node graphs.
This holds all the Tools connected to the View, and provides more principled lifetime management between Views and Tools (formerly, `Tool::m_view` could be invalid if the View dies first). Parenting tools into the View is also a step towards the full serialisation of layout state discussed in GafferHQ#50. The eventual idea is that if the UI is a hierarchy of GraphComponents, then it can be serialised using the same mechanism used for node graphs.
This holds all the Tools connected to the View, and provides more principled lifetime management between Views and Tools (formerly, `Tool::m_view` could be invalid if the View dies first). Parenting tools into the View is also a step towards the full serialisation of layout state discussed in GafferHQ#50. The eventual idea is that if the UI is a hierarchy of GraphComponents, then it can be serialised using the same mechanism used for node graphs.
I'm not sure if this is the right long-term fix or not, but it works for our immediate needs (a custom Tool subclass with a ColorPlug). It wouldn't work for, say, a plug in the LightEditor settings, where there's no way of finding the script from the parent-less settings node. As discussed in GafferHQ#50, it might be ideal if the entire UI hierarchy was specified via Nodes/Plugs, and then this approach could work for the LightEditor and everything else too. An alternative approach would be to pass a `forWidget` argument to `acquire()` and then find a suitable parent window for the dialogue from that. But that is a bit harder to use, and also means we could end up with multiple colour dialogues (under different windows) for the same plug, which is what we're trying to avoid.
I'm not sure if this is the right long-term fix or not, but it works for our immediate needs (a custom Tool subclass with a ColorPlug). It wouldn't work for, say, a plug in the LightEditor settings, where there's no way of finding the script from the parent-less settings node. As discussed in GafferHQ#50, it might be ideal if the entire UI hierarchy was specified via Nodes/Plugs, and then this approach could work for the LightEditor and everything else too. An alternative approach would be to pass a `forWidget` argument to `acquire()` and then find a suitable parent window for the dialogue from that. But that is a bit harder to use, and also means we could end up with multiple colour dialogues (under different windows) for the same plug, which is what we're trying to avoid.
I'm not sure if this is the right long-term fix or not, but it works for our immediate needs (a custom Tool subclass with a ColorPlug). It wouldn't work for, say, a plug in the LightEditor settings, where there's no way of finding the script from the parent-less settings node. As discussed in GafferHQ#50, it might be ideal if the entire UI hierarchy was specified via Nodes/Plugs, and then this approach could work for the LightEditor and everything else too. An alternative approach would be to pass a `forWidget` argument to `acquire()` and then find a suitable parent window for the dialogue from that. But that is a bit harder to use, and also means we could end up with multiple colour dialogues (under different windows) for the same plug, which is what we're trying to avoid.
Add a user preference whether to restore layout from .gfr file when loading or not.
Users may not (for example) want to get the window layout when opening someone else's work.
The text was updated successfully, but these errors were encountered: