Open bentoogood opened 11 years ago
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:
I think this would break down something like the following :
- Somehow save the current layout in the .gfr file when serialising. This should probably be saved as metadata, but I’m not totally sure what mechanism to use to get it there.
- Add some preferences to determine whether or not the saved layout should be restored when loading a file. Have the FileMenu (or the ScriptWindow?) do the right thing based on those preferences.
- Figure out how to save the pinning. Again, I think this should be stored as metadata, but I’m not sure if it should be separate metadata or if it should be part of the saved layout. I presume we wouldn’t want to save the pinning when saving a named layout via the Layout menu?
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...
elaborate on the workflows where saving the layout in a script is most useful
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).
Lookdev
Lighting
FX
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?
Lookdev
Lighting
FX
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.
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 View
classes used in the Viewer. Views use plugs to specify all their settings, and it has been working out well. We get a UI framework for editing the settings for free. We get signalling of state change for free. We get introspection for free. And we get to reuse API instead of invent more. But switching all that up for all the editors is a big task.
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?
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.
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.