On a vanilla invocation, `wine-pyinstaller.sh` will prepare a
Python-3.5 environment under Wine-3. The current requirements to run
the script are following:
1. p7zip-16.xx
2. Wine-3.xx
3. WinPython-3.5.4
All of [1-3] are available in Debian Testing or Ubuntu Bionic
repositories.
P.S.
WinPython was used since official Python-3.5.4 from Python.org wont
run under Wine. Python-3.6 is not supported yet under Wine-3.xx.
A default `npm run build` or a `scripts/build.sh` invocation would
not compile or sign `native_main.exe` anymore. This is a departure
from the previous logic where `PYINSTALLER=0` was needed to prevent
compile+signing of `native_main.exe`.
The following is achieved with this commit:
```
$ ## following does _not_ compile/sign `native_main.exe`
$ npm run build
$ PYINSTALLER=0 npm run build
$ ## following _does_ compile/sign `native_main.exe`
$ PYINSTALLER=1 npm run build
```
NB: this is actually bootleg. All complaints about added jank should go
to @bovine3dom, who will provide copious helpings of empathy, but
probably won't be able to fix it.
DOMContentLoaded is never fired for ImageDocuments and
document.readyState doesn't behave the way we want.
Turns out you can just append immediately, though, so we do that.
This patch replaces the previous `-UsePython` flag with `-NoPython`.
Essentially this flag replaces the native messenger installation
behavior with the following new strategy on Windows:
* Look for Python-3 in user's Windows environment
- If Python-3 is found, install `native_main.py` as the native
messenger binary
- If Python-3 is _not_ found, install `native_main.exe` as the
native messenger binary
- Get csp setting asynchronously
- Case insensitively match content-security-policy header value
- Parse csp correctly
- Simplify code
(When I rebased last time I lost the content of this commit somehow...)
