* This is a bit less ambiguous and less confusing in the case where
someone is expecting a "compile" type button instead of "save changes"
type button.
* These .py wrappers are relevant for the non-builtin path, but since we
use -builtin they serve no purpose except to make things more complex.
* So instead we make the module directly exported as 'module' instead of
'_module'.
* On windows there's no conflict because we have renderdoc.dll vs
renderdoc.pyd. On linux it's librenderdoc.so vs renderdoc.so.
* To prevent supporting files like .lib / .pdb from conflicting on
windows we build the python modules into a subdirectory. They're not
ever used by the UI (it links in the bindings directly).
* We split the "update available" off to a top-level menu item, instead
of a sub-item under Help. This gives explicit text saying an update is
available.
* Change the icon from an hourglass to a slightly more 'updatey' image.
* We now re-cehck every week even if an update is marked available. That
way people who delay for longer than it takes to release a new version
will get the latest when they do update. It also gives them a reminder
every week so that hopefully those delayers will be less common!
* The UI dialog is now in Qt. We run qrenderdoc.exe with a very minimal
startup to display the dialog and send the report.
* The flow has been simplified to have less text and an easier time to
just click through and send.
* On the first report, the user is gently nudged to enter their email
address for contact and by default the email is saved for next time.
They're not nagged more than once about this.
* Optionally the user can select to upload the capture. This is always
default off, and there is a confirmation dialog making sure the user
intended to select it.
* After the bug is reported, a unique URL is generated and returned
which the user can then click back on to see if there's any update. By
default the UI will also remember the URL and check it every couple
of days and alert the user in the help menu that there's an update.
* 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.
* 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.
* 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.
* Tacking -official onto the git hash was a hack only needed on windows,
and since we want more information it doesn't scale.
* Instead we track anything we need to know about the version in
separate variables, like whether it's a stable build or a nightly/
local build. Or if it's built by a downstream distribution then the
version number for the downstream build.
* 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