* Previously we would convert from python to C++ arrays immediately by
copying, and vice-versa convert TO python immediately by creating a
new python list by copying.
* This however behaves rather poorly in common situations, e.g.:
> foo.bar.append(5)
Would not append 5 to foo.bar, but copy foo.bar to a temporary, append
5 to it, then destroy it leaving foo.bar untouched.
* Instead we leave the C++ array type as a pointer for as long as we can
and instead implement the python sequence API as extensions/slots that
work in-place on the original array.
* 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>
* For the most part the interface is stl-compatible, but we have a few
little changes of our own for convenience.
* This class is still needed after deleting the C# UI, because we don't
want to pass C++ stl structs over module boundaries and possibly run
into hard to diagnose incompatibilities.
To quote the Qt documentation for QFileDialog::setNameFilters:
> Note that the filter *.* is not portable, because the historical
> assumption that the file extension determines the file type is not
> consistent on every operating system. It is possible to have a file
> with no dot in its name (for example, Makefile). In a native Windows
> file dialog, *.* will match such files, while in other types of file
> dialogs it may not. So it is better to use * if you mean to select
> any file.
Admittedly, one of these usages is Windows-only and we are using the
native file dialog there, but we might as well be consistent.
Instead of manually specifying the default extension, just grab the
first one from each filter. We can only specify one at a time, so
update it whenever the selected filter changes.
In most of these cases, the open file dialog won't even display a file
without the proper extension, so this helps ensure the user doesn't
accidentally misplace their files. The one exception is *.rdc, which
could be found without the extension, but could not be opened.
* The former is only needed inside tp_init of a new object. Instead when
we want to pass in and own a pointer, we use SWIG_POINTER_OWN.
* This also removes the need to pass 'self' all the way down in
ConvertToPy which tidies up a lot of code.
* This allows a buidler to customise from e.g. /usr/lib/librenderdoc.so
to /usr/lib/renderdoc/librenderdoc.so - which is harmless since the
library is 'private' and not intended to be linked against directly.
* 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.
* There was no good reason to have a flag indicating if the special
format was valid or not. Now it's a single enum, with a value
'Regular' indicating that the compCount/compWidth/compType fully
describe the format itself.
* This makes code patterns easier as you no longer need to check for
special then check for specialFormat, you can just test the type
directly.
* The bug seems to happen if two raw strings concatenated together are
large enough, so instead we pass them as separate parameters to a
different macro then concatenate them inside the macro.
During initial scan of application, detect if root access is available
and track it. If user later selects "Click here for ways to fix this".
display a new dialogue that offers to push the layer directly.
If pushing fails, fall back to production dialogue.
Also add a new persistent setting to enable automatic layer pushing.
* In future we could handle async exceptions by storing the exception
information in a std::function derived object (instead of the separate
ExceptionHandling that lives on the stack) and query it out in a new
WaitForInvoke function maybe. Right now we just print the exception
to the output log and abort the callback.
* 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.
baldurk