* 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