* We add a button with a link icon to indicate that it goes to the
resource details. We'll re-use the crosshair as a visual metaphor for
any interactive widget that goes to the resource inspector.
* To remove any possible confusion, we change the icon for the texture
list and locked tabs in the texture viewer to not include the link.
* Note that while this is public and uses std::string, because it's a
template with specialisations in a .inl the string never crosses a
module boundary - each including module has its own implementation.
* This will be used as part of the upcoming serialisation refactor.
* Some POD structs are still given ToStr implementations as we haven't
yet switched over the serialisation system to expect all structs to
have serialise functions.
* We have some special handling to allow SWIG wrapping of these types:
SDFile owns the chunks and buffers within, and each object owns its
children. Copying is disallowed except from SWIG where we assume the
wrapper is handling lifetime management for its objects externally.
* Previously we would convert from python to C++ arrays immediately by
copying, and vice-versa convert TO python immediately by creating a
new python list by copying.
* This however behaves rather poorly in common situations, e.g.:
> foo.bar.append(5)
Would not append 5 to foo.bar, but copy foo.bar to a temporary, append
5 to it, then destroy it leaving foo.bar untouched.
* Instead we leave the C++ array type as a pointer for as long as we can
and instead implement the python sequence API as extensions/slots that
work in-place on the original array.
* We need to custom paint the SVG at the right devicepixelratio because
Qt seems to be busted at scaling up - nothing I can see causes the
SVG to be rendered at higher than it's default resolution, so you end
up with plain bilinear upscale.
* Since we're doing custom palette swap anyway, it's not much harm to
just render ourselves, as we already basically had a dependency on
QtSvg - just need to add the include files to the dependencies.
* The idea is tha this style won't change the palette and will just do
some minimal additions/changes to whatever the native style is, to
work around some rough spots.
* We can point the platform plugins path at the application dir for
qwindows.dll for example, but there's no equivalent for image format
plugins which we need for qsvg.dll. So instead we shove them all under
an explicit qtplugins path.
* Also now that we have this, copy qsvg.dll into the distribution.
* Annoyingly although Qt has an internal bool allowUserMoveOfSection0
which does exactly what we want allowing the tree column to be
movable, we can't enable it because it's private. So instead we have
to re-implement section moving ourselves.
* Minor tweak - also made RDTreeWidgets non-movable by default since
usually we don't want to allow it.
* Added a couple of utility macros to help with the conversion. lit() is
paired with tr() for untranslated text.
* QFormatStr is more explicitly for non-textual formatting strings.
* Both are just #define'd to QStringLiteral()
* By default VS creates a huge section of properties copy-pasted for
every Configuration|Platform combination, which is almost all the
same for each one.
* We instead create a common section with most of the properties that
are fixed, and then override/add to them for the few that vary (e.g.
optimisation settings for release, preprocessor macros).
* Note, this API is still in-flux and beta, so there may still be some
more changes before it's 'stable', and even then it will still be
subject to some amount of change.
* This API is then exposed to python via SWIG bindings and hides
internals that don't need to be visible, and means the actual API is
easier to work with.
* We also use this API to reduce inter-dependencies between different
windows that need to interact with each other at a high level.
* The naming is python/standard RenderDoc TitleCase method names, not
Qt style camelCase methods.
# Conflicts:
# qrenderdoc/Windows/PipelineState/D3D11PipelineStateViewer.cpp
# qrenderdoc/Windows/TextureViewer.cpp
* SWIG outputs two files - renderdoc_python.cpp with the main actual
wrapping code, and renderdoc.py a small module that does some
bootstrapping on python side.
* We use a custom version of SWIG that generates strong/typed enums in
python based on enum classes, so in cmake we add this custom swig
fork as an external project and compile it before generating the
wrappers. On windows there's a committed version of the SWIG binary
that gets run directly from the .pro or .vcxproj.
* The renderdoc.py gets embedded as a resource on windows or as a C
generated unsigned char array via include-bin on other platforms, so
that we can insert it into the python context without needing it to
sit around on disk somewhere in sys.path
* Apart from making the code cleaner when accessing them, creating these
from strings can be slow if you do it often enough (e.g. once per
resources for action/action_hover in pipeline state view).
baldurk