Use native widgets to render main scrollbars (scrollbars of the
main webview widget, not iframes etc).
It makes the scrollbars on body element invisible and instead draws
native widgets on the space for scrollbars.
Comes with possibility to disable it, enabled by default.
* Add initial printing support with QtWebEngine >= 5.7.0
This works by printing to PDF first, then sending the PDF to a printer
if printing to a physical printer was requested.
On *nix (including Mac OS X), we use the lpr command, which is typically
provided by CUPS nowadays. Currently, no options beyond the printer name
are passed, there is room for improvement there. (Okular has a
FilePrinter class that handles this in a more sophisticated way.)
On Windows, we use ShellExecuteW with the "printto" verb. In that case,
the printer name is unfortunately the only thing that can be passed. The
user experience may also be suboptimal depending on the PDF viewer
installed on the system. (E.g., Adobe Reader is reported to ignore
SW_HIDE.) And if there is no PDF viewer installed at all, it will of
course not work at all. But it is the best we can do without bundling
something like GhostScript (or requiring the user to install it).
* Printing: Let lpr autoremove the temporary file instead of QTemporaryFile
Only lpr knows for sure when it is safe to delete the temporary file.
* Printing: Use the callback version of printToPdf instead of the file one
The file version is also asynchronous and does not report when it is
done.
* Printing: Use async QProcess API instead of QProcess::execute to run lpr
This also required making tempFile a QTemporaryFile * instead of a
QTemporaryFile on the stack, because QTemporaryFile is a QObject and
cannot be copied.
* Printing: Adapt the FilePrinter from Okular to pass correct lpr args
The license of those files is GPLv2+, which is compatible with
QupZilla's GPLv3+ licensing.
* Repair current OpenSSL static reference from homebrew
* These are the default locations, as of today, for Mac OS X 10.11.4 *(El Capitan)*
**NOTES**
* This could really use some environment variables for homebrew root and which SSL version is in use. Not familiar enough yet with recent Qt to do this at this time.
* Symbolic links could also be used but again determining the current homebrew SSL installed is something to be desired e.g. similar to `$ openssl version` e.g. perhaps a `cut` of `$ brew info openssl`?
Refs:
* http://brew.sh/ *(homepage)*
* https://github.com/Homebrew/brew *(repo)*
Historical refs:
* #1888
* #1850
* Mac: Scrape `brew` output for openssl working install directory as per @nowrep
* Addresses a long standing bug on Mac compiling with this project
* Also correct the BUILDING markdown file for OS X... was awaiting response from the owner to do this to see which direction to move.
**NOTES**
* Quotes **are required** when using `$$system` here otherwise `cut` fails with no switch argument found
Applies to #1971
* Fix BUILDING to BUILDING.md
* Do this so it actually parses markdown
Indirectly related to #1971
* Fix `brew` to Homebrew
* Even though the project is named `brew` and owner is `Homebrew` their pages refers to it as `Homebrew`
Applies to #1971
* Yet another change
* There are more symlinks... so the results from `brew --prefix openssl` yields a symlinked path and adding `/include` and `/lib` to them resolve alternately to the `Cellar`. Feel **much** better about using this one since it's an exact API as I mentioned earlier in the PR
Applies to #1971
* Add a single newline for @cranes-bill
* Only one newline is needed and has nothing to do with trailing spaces... at least according to the GH editor
* Restores the flow :)
Applies to #1971
* More flow of README.md
* GH preview said it didn't need this but I guess it does... we'll try newlines everywhere ;)
Applies to #1971
* Use non-standard markdown for "newlines"
* Restore the spaces manually
**NOTES**
This is not any known specification but it's what @nowrep wants
Refs:
* [CommonMark](http://commonmark.org/)
* [Daring Fireballs](http://daringfireball.net/projects/markdown/)
This is first quick port to QtWebEngine, most of advanced features
are not working yet. Please read README.
For now, it will use separate profile directory as well as browser
session, that means you can use both QtWebEngine and QtWebKit versions
at the same time.
