Save layouts with script

[bentoogood]

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.

[johnhaddon]

When we do this, it'll be very nice to also store the NodeGraph zoom settings in the layout.

[andrewkaufman]

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.

[themissingcow]

@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...

[andrewkaufman]

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

  • Oh absolutely yeah, it'd be nice to be able to get our scripts with all pinned content/layout to open up the exact same way we left it upon closing it.
  • Right now every time we open a script we have to re layout everything, re pin all our little useful toolboxes and render previews etc etc. Its not that much of a big deal in itself, but it'd sure be nice not to have to do that every single time.
  • Especially when it comes to crashing several times when troubleshooting, it can easily add up, having to re setup everything every time.
  • I have a default template and default layout for when I start something new, but then I start working and messing things around, pin tools and tabs that weren't initially needed in my basic template scene, and this is when it'd be nice to get the layout saved, because if I crash, I'll have to re do it all again.
  • My pre-saved layout is only good for the existing nodes in my default template, so in the case of scripts that might have different content I would need a preset per script, but that becomes a little much...

• Lighting

  • This would be super useful. Every time I open my script, the first thing I do is go to each of my (many) tabs and pin to specific nodes or focus the graphs to specific nodes. It'd be great if that was all saved and ready to go as soon as I open the script.
  • My default layout has 2 pinned NodeEditors, 2 pinned Viewers, and 2 pre-focused GraphEditors, plus a slew of other unpinned tabs, spanning across 2 widescreen monitors. Its a lot of navigation to get it all set up right now.
  • Yeah, I could use bookmarks, but that still requires several clicks, and typing, and positioning my mouse a lot. It doesn't sound like much, but it adds up. Saving numeric bookmarks would make that easier for sure, but I'd still prefer saving the whole state of the layout.

• FX

  • Let's say I have 50 shots that have an identical element that I need to run. Maybe I need to tweak the key light direction, the density of the shader, and let's say pscale [width]. In my personal workflow I would pin the 3 nodes that control this including my preview node. Every time I open my scene I would want this layout to load so I can hammer through these shots without repeating the same layout set up 50 times or more.
  • But even if you are working on the same shot and you just close and open your scene I would want the panels to persist.
  • Yes. I do change my default layout, but I would also want my scripts to save my adjusted layout.
  • Imagine you are driving a car and every time you get in it, your seat, side mirrors, rear view mirror don't fit your preferred configuration...

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

  • Sure, that'd be handy actually, then a Gaffer script becomes a little user personalized entity in itself, and if you open one up, you end up seeing exactly what the script creator was seeing.
  • That'd also help for debugging, because in certain cases it could just be a matter of not looking at the right thing, and that would avoid a "it works here when I try it" kind of situation
  • I can see how it could potentially be annoying when opening someone else's scene, but in the case of a take over then it'd make sense to re do our own layout. But for troubleshooting, and without our own work, being able to re open a scipt after crash or even normally re opening some work and having everything "there" would be awesome.

• Lighting

  • I wouldn't want to force my layout onto other people. Maybe it should be a user preference to apply the script layout or not.
  • I can see how it'd be handy to debug someone's script if they pre-pinned nodes for me to look at.

• FX

  • If their pinning comes up I can always go to the layout menu and switch the layout to default. Sure it might be a bit disorienting at first, for a moment, but nothing is stopping you from switching it back to your own default.

[themissingcow]

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.

[johnhaddon]

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?

[andrewkaufman]

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.

[themissingcow]

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?

[andrewkaufman]

This is by no means conclusive, but using the same 3 users I canvased before and going off what they told me back then:

• Lookdev
  • Both the layout and pinning are specific to each script
• Lighting
  • The layout is custom but used unchanged with most scripts, the pinning is specific to each script
• Fx
  • Both the layout and pinning are specific to each script

I suspect that reflects the type of work done in those departments most often:

• Lookdev
  • Very chaotic graphs which are totally bespoke to each asset/character
• Lighting
  • Very consistent graphs which can run entire sequences (if not shows)
• Fx
  • Consistent graphs per type of effect, but there are a lot of different types of effects

[themissingcow]

Thanks Andrew, that’s really helpful. Appreciate the time in research.