* 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.
* 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()
* 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
* Previously the cmake build would put librenderdoc.so in a /bin folder
in the source folder so the qt creator project could link against a
fixed path when just opening the project solo.
* This won't scale though for fetching the SWIG outputs from cmake, and
it's ugly to modify the source folder for out-of-source builds.
* Instead we have cmake generate a qt creator include file with all of
the settings and paths needed, and pass the CMAKE_BINARY_DIR into
qmake when building. This does mean that when opening the project in
qt creator you need to specify CMAKE_DIR=/path/to/build though.
* As a bonus, this means we can let cmake identify where python is and
have qt creator link against it rather than having to hardcode include
paths etc.
In some cases when the renderdoccmd/qrenderdoc is linked the linker
ignores the libEGL.so and only uses the librenderdoc.so.
This is because the renderdoc shared library provides the
same symbols as the libEGL.so. However we need to keep the
libEGL.so as we are using RTLD_NEXT in the renderdoc shared
library.
* 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).
* When cmake custom commands invoke make, the make execution is silent.
The MAKEFLAGS reset was to remove the silent flag, but it also lost
the -j parallel build flags.
* Instead, we set qmake to silent mode (which it already was going to
be), and that causes it to add echo statements to each rule that will
be printed even when make is silent.
Matthäus G. Chajdas