* 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.
* Menus aren't guaranteed to pass isVisible() immediately after calling
popup() on them, so we need to wait for their aboutToHide signal to
stop the event loop.
* We forward a different range of ports to each device so we can pick
and choose which to communicate with based on its index.
* The index is encoded in the 'hostname' like so: adb:X:deviceidhere
* Whenever we want to interact with an android device we always specify
the device, never leave it to a default.
* This fixes a crash where an enumeration from application startup is
still going when opening the remote manager dialog, and then all the
android hosts that are being enumerated get deleted while it's still
going.
* 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.
* Even if we don't have pyside2 to treat qwidgets as full objects and
access their methods and data, we still need to be able to pass around
the QWidget* as an opaque pointer to be able to use the API properly.
* This change falls back to just using SWIG's default opaque pointer
wrapping and unwrapping when pyside2 isn't available.
* Any work that might use Qt needs to happen on the UI thread, so when
running a python script on the python thread we need to invoke across.
We wrap the main ICaptureContext interface to block invoke onto the UI
for any function calls that aren't just returning internal data.
* The error handling code will be OK if a NULL parameter was passed in
but during cleanup it will go through tempdealloc, so we need to check
that the pointer is actually valid.
* QShortcut falls down on duplicates. It can have activatedAmbiguously
events, but these happen in arbitrary order and the shortcuts on
menu items just swallow the ambiguous activate so it's not useful.
* Instead we just let MainWindow pick up ShortcutOverride events and
consult a mapping of which shortcuts to use. We can use a smarter
selection method to choose the more 'local' shortcut if two shortcuts
that conflict exist.
* This really isn't ideal as it means the python module will only work
with that specific major.minor version of python, when it could in
theory work with any python version above 3.2 or so, depending on what
features are used.
* Since we're not distributing these modules yet though, add this
linking to support -Wl,--no-undefined.
* 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.
baldurk