* If the remote host disconnects during the selection process we will no longer
have a valid connection, we shouldn't sanitise the resulting path according to
local filenames.
* We add a capture option that defines a soft limit we aim to keep under for
memory overhead during capture, excess initial states after that will be
stored temporarily on disk.
Use QTextBrowser for the counter description widget, which allows for opening
links in an external browser.
This change is needed to make the link to NVIDIA Nsight Perf SDK clickable.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* The 'no to all' option should always be present if there are multiple unsaved
captures across the connections, even if the current connection only has one
capture and so otherwise wouldn't have a 'no to all' option.
* The 'no to all' option will always discard all unsaved captures in all
connections when closing the window, if the user clicks no on the confirmation
of this, abort the close operation entirely and let them decide how to handle
it (e.g. discarding/saving captures in connections individually).
* This means if you're closing multiple connections and click 'no to all' when
prompting save of instead of discarding just the captures in that connection
then going on to prompt for the next, it discards all remaining captures.
- Add a new combo box and button to camera settings for mesh viewer
- Add a new dialog window for custom axis mappings
- Implement the axis mappings in gl driver (other drivers to come)
* If we save the current capture from a connection window we want to do that via
the main window so the UI can be properly updated and so we can save it
properly through the replay manager, so the old one can be removed safely.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* This option (in spite of large warnings) continues to be a pitfall for new and
experienced users alike, trying to use process injection without good reason
and getting into trouble when it breaks.