* This has some possible problems - e.g. if one copy of qrenderdoc is closed and
kills the server used by another copy. However it seems impossible to reliably
manage adb and we need to ensure we don't leave the process lingering around.
* At the moment 95% of users don't use android, so it's most important that they
have a smooth experience.
* This was the cause of problems around updating versions because adb.exe would
hang around and then be 'in use' and not able to be overwritten.
* 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.
* This is a *very* light-touch analytics system that will track the
simplest and most anonymous statistics that can be useful in
determining which features are most used or perhaps underused, and
where it's best to direct development attention.
* It is entirely implemented in the UI layer, no analytics-gathering
code exists in the library that's injected into programs, and of
course no capture data (screenshots, resource contents, shaders, etc
etc) is transmitted.
* Once it's turned on, it will apply to both development and release
builds. It tracks stats over a month, and then at the beginning of a
new month it sends the previous data.
* When the user first starts up a build with analytics if there's no
previous analytics database then they are informed of the new code and
asked to approve it. They have the option of selecting to manually
verify any sent reports, or just opt-ing out entirely.
* This is a leftover from before the interface was hoisted out, and most
windows were still calling directly to CaptureContext instead of via
the public ICaptureContext interface
* Since these types are more prevalent than originally designed, it
makes more sense to remove the namespace for ease of typing/naming.
* Also add a specialised type 'bytebuf' for an array of bytes.
* This makes mapping easier to SWIG since there's no special casing for
namespaced arrays. Especially so for nested cases like
rdctype::array<rdctype::str> -> rdcarray<rdcstr>
* Instead of checking on the filename, we look for a specially named
exported symbol somewhere in a module that's already loaded.
* This allows us to mark the python module as a replay program, so if
it's loaded into the python interpreter it will be able to use the
replay API.
* 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.
* It's not entirely clear if this is the intended fix, but otherwise
since we're not running QApplication::exec() the main event loop has
the same 'loop level' of 0 as the event level when it's fired. The
proper functioning seems to be that the posted deleteLater event
should have an event level of 1 which then means it will be processed
when coming back to the exec() loop level of 0, but since we don't get
that, just run it manually after all other events.
* 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()
* If a window (like the PythonShell) owned a context and only stopped it
on destruction, it would be destructed after the global shutdown
destroyed the interpreter.
* 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
* This gives a little nicer syntax, a bit better type safety, and also
reflects better for SWIG bindings. Overall it's a minor change but
better.
* We don't update the C# UI at all, since it's soon to be removed and
not worth the effort/code churn.
* For now so we're ABI compatible with C#, all enums are uint32_t, but
that is an obvious optimisation in future to reduce struct packing.
* We avoid 'None' as an enum value, because it's a reserved word in
python so will cause problems generating bindings.
* 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