Save last known location of closed docking windows

[PfhorSlayer]

Description

(Note: I believe I reported this before, but can no longer find it in the issues list. The bug still exists in v1.2, so I'm re-posting it. Apologies for the double post, as I was previously logged in with the wrong account!)

When using the RenderDoc API to initiate a capture from my app, the instance of RenderDoc that is launched to display the capture does not retain my docked tab layout from the last instance I ran.

As a concrete example, I have the Texture Viewer tab un-docked into its own window and placed on a second monitor. When performing a capture, the instance of RenderDoc that opens places the "Connection" tab (containing the API information and the list of all the captures that have been taken for that connection) docked inside the Texture Viewer window. Each time this happens I manually drag the Connection tab back and dock it with the other tabs (Pipeline State, Mesh Output, Resource Inspector, Launch Application), but when I re-run my program and take another capture, RenderDoc opens up and places the connection tab docked with the Texture Viewer again. I would expect that RenderDoc would either remember where I have asked the Connection tab to be placed, and place it there, or choose to dock it by default in the main RenderDoc window, rather than next to any other tabs that I've pulled out of that window (alternatively, always dock it next to the Launch Application tab).

Repro steps

Reset RenderDoc layout. Drag the Texture Viewer out into its own window, leaving the other tabs alone and docked in the main RenderDoc window. Exit RenderDoc.

Re-open RenderDoc, and notice that the Texture Viewer is still out in its own window, as expected. Exit RenderDoc.

Use the API to take a capture of an application. Notice that the "Connection" tab has been docked next to the Texture Viewer. Manually move the Connection tab and dock it next to the others in the main RenderDoc window. Exit RenderDoc.

Repeat the above capture step, and notice that the Connection tab is again spawned docked next to the Texture Viewer, instead of where it was placed manually.

Environment

• RenderDoc v1.2
• Windows 10
• D3D11

Granted, this is a VERY minor nitpick, but given that everything else in RenderDoc remembers how I set it up and keeps track of my preferences, it would be really nice if this did as well.

[baldurk]

The layout saving only saves the location of panels that are open. Any closed panels don't have their location remembered, and when they re-open they reopen in a default location. For temporary panels like constant buffer views, capture connections, shader viewers, etc, the location is thus never saved. Some of those dock to the same panel as whatever opened them, but for some that isn't feasible.

There's also an extra problem that there's not a defined 'main' area for most new panels. Since the layout is fully customisable what I do currently is go down a priority list of windows to use as a proxy for the 'main' area, and first on that list is the texture viewer so most things get docked with it. What's considered the main area by the user subjectively is quite difficult to exactly define algorithmically.

I could add some logic that looks at all the open panels in that priority list and if it finds an odd-one-out that's docked in a floating window by itself, then exclude it. However that easily breaks down if you only have one other window open and docked, e.g. the pipeline state, or maybe you have the pipeline state docked in its own floating window. Even with a tie-break rule to favour the main window over floating docks it's not a very general solution.

Saving the last known location where a given panel was docked last time it was open has a number of problems. The layout is saved as a single hierarchy and relative-references (like 'left of the texture viewer' or 'docked to the pipeline state view') are only valid when first inserting a panel into the hierarchy. I'm not sure how you'd represent a dock location unless it's the case of being docked to the same panel as an existing open window. You can create docking layouts where a panel isn't easily just 'right of X', and there's no guarantee the reference even still makes sense when trying to use that information.

I'll see if I can think of some better logic, and I can at least implement the above weak heuristic to avoid favouring floating windows in some cases. For capture connection windows I can also favour pairing them with the capture dialog if it's open at least.

[PfhorSlayer]

Thanks! I think probably just pairing the capture connection with with the capture dialog (the Launch Application one, right?) would be the easiest fix and have the least number of edge cases here. UI always is the hardest part to get right, as it'll never behave exactly how every single person wants it to. :)

[baldurk]

That commit will favour the capture dialog when it's open as mentioned above.

I'm going to leave the issue open because I think this feature would be nice, but the main problem is how to store the location where a panel would open without it actually being part of the docking hierarchy. Realistically I doubt I'll get around to this any time soon.