* From https://github.com/Riateche/toolwindowmanager
* It seems superior to the built-in Qt docking as-is, and since it's
a few open source files it should be easy to improve with features
we might want to match DockingUI functionality.
* Programmatic sizing for the default layout seems inflexible, but since
that's a one-time thing it's not the end of the world.
* There's no auto-hide functionality.
* The highlighting of where to drop could be improved, as well as the
detection of where to drop (currently it seems to cycle through
several possibilities each second rather than having a consistent drop
location).
* Floating windows could be styled a bit better.
* Need to check whether we can have nested docking sections (so the
texture viewer e.g. can have its own docks, that won't float or go out
of the texture viewer.
* Building qrenderdoc on windows will be supported just because that's
likely where I will be developing it mostly, but for the foreseeable
future it won't be built by default. If it ever gets good enough to
replace the .NET UI, then we can look at it again.
* It's quite hacky at the moment since it doesn't read out the data in
a structured way, just enough to disassemble. For now it's a proof of
concept kind of thing.
* This is tracking my fork of the Khronos repository
https://github.com/baldurk/glslang on branch 'renderdoc'. See that
branch for my local changes. Only a subset of files is included
* This means that rapidly creating and destroying views doesn't 'leak'
and create more and more chunks in-program and more and more uselessly
created views on replay.
* The old code in m_RangeMax/m_RangeMin setters wasn't doing proper
epsilon enforcing so min=max could end up happening. It's easier to
set both at once (this is all we care about anyway) so that it does
properly make the min and max distinguishable.
* There were two bug reports of NullReferenceException on line:
hoverWin = m_HoverNode.OwnerView;
* Which doesn't make sense since m_HoverNode must be non-null to go by
the lines above, and all the callbacks should run on the UI thread so
it can't be a race.
* Caching locally and checking for OwnerView/ListView being valid might
fix the crash. Hopefully!
* Tweaked flycam a bit too, but not much.
* Refactored the API/C# side camera classes to avoid exposing a ton of
stuff just to do relative rotations in the arcball via quaternions.
* The arcball lookat position can also be dragged with alt-click or
middle click.
* Also supports other elements as position not just magically-selected
"POSITION" element.
* Should mean the 'target' of the render target will be selected by
default now when clicking to an event, without annoyingly switching
away from what you were looking at.
baldurk