Re: KIO and cookies
On martedì 31 ottobre 2017 22:33:24 CET Allan Sandfeld Jensen wrote: > On Dienstag, 31. Oktober 2017 21:17:35 CET Stefano Crocco wrote: > > On martedì 31 ottobre 2017 01:47:37 CET Allan Sandfeld Jensen wrote: > > > On Sonntag, 29. Oktober 2017 09:47:24 CET Stefano Crocco wrote: > > > > Hello to everyone, > > > > I'm working on making QWebEngine work correctly in Konqueror when > > > > downloading files (although I didn't have much time to spend on this > > > > in > > > > the > > > > last months). > > > > > > > > The problem is that instead of downloading the correct files, in some > > > > cases > > > > Konqueror download html files. This only happens from sites requiring > > > > authentication (I first noticed when trying to download a file from my > > > > bank's web page); besides, it only happens if I try to use KIO for the > > > > download, for example calling KIO::copy from a slot connected with > > > > QWebEngineProfile::downloadRequested. The file downloads correctly if > > > > Konqueror downloads it using the mechanism provided by QWebEngine, > > > > that > > > > is > > > > calling QWebEngineDownloaditem::accept. > > > > > > > > I believe that the issue is caused by cookies, and in particular by > > > > the > > > > fact that QWebEngine doesn't share its cookies with KIO so that, when > > > > KIO > > > > attempts to download the file, it doesn't have the cookie(s) > > > > associated > > > > with the session opened in the browser and the web page refuses to let > > > > it > > > > download the file (indeed, one of the sites where this happens > > > > returned > > > > a > > > > login page instead of the PDF I wanted to download). > > > > > > > > Looking at the documentation both for QWebEngine and for KIO > > > > regarding cookies. I found out two classes: > > > > * on QWebEngine's side, there's QWebEngineCookieStore, which provides > > > > signals emitted whenever a cookie is added or removed and which, > > > > according > > > > to documentation [1], "can be used to synchronize cookies of Chromium > > > > and > > > > the QNetworkAccessManager" > > > > * on KIO's side, there's KIO::Integration::AccessManager, which > > > > derives > > > > from QNetworkAccessManager and which should work along > > > > QWebEngineCookieStore. > > > > > > > > The example in the documentation for KIO::Integration::AccessManager > > > > refers > > > > to QWebView and says to call QWebPage::setNetworkAccessManager to have > > > > the > > > > QWebView and KIO to use the same access manager. Unfortunately, > > > > QWebEngine > > > > can't be integrated with a QNetworkAccessManager: not only > > > > QWebEnginePage > > > > doesn't have a setNetworkAccessManager method, but the documentation > > > > for > > > > QWebEngine explicitly says that it doesn't use QNetworkAccess. Because > > > > of > > > > this, I thought to do things the other way round: I created a > > > > KIO::Integration::AccessManager and, used slots connected with > > > > QWebEngineCookieStore signals, to add cookies to it. > > > > > > > > Unfortunately, this doesn't fix the issue. I believe this is because I > > > > haven't told KIO to use the new access manager. The problem is that I > > > > can > > > > see any way to do it. Does anyone have suggestions on how to do this? > > > > > > KIO has its own cookie-store separate from QNAMs cookie store. So there > > > are three cookie stores. QtNetwork's, KIOs, and QtWebEngine's. Of course > > > the easiest solution would be to let QtWebEngine handle the downloading, > > > but that wouldn't integrate into normal KDE download mechanisms. So you > > > need to bridge QtWebEngine's cookies into KIOs cookie store and ignore > > > QtNetwork's. > > > > > > 'Allan > > > > The problem is that I can't find any documentation on how to interact with > > KIO's cookie store. On KIO::AccessManager, it is stated: "IMPORTANT This > > class is not a replacement for the standard KDE API. It should ONLY be > > used > > to provide KDE integration in applications that cannot use the standard > > KDE > > API directly". Unfortunately, it doesn't mention which is the standard KDE > > API. Looking at accessmanager.cpp, I see (in the code for > > KIO::Integration::CookieJar) DBUS calls to the "org.kde.cookiejar5" > > interface. Is this the "standard KDE API"? If so, is there a place where > > it's documented? I think I already tried to use it to solve this problem, > > but without success. However, tomorrow I'll give it another try. > > I am not sure how well it is documented, but yes, it is essentially a DBUS > api in background, because the cookie-jar runs in a separate process. > Perhaps you can find some help by looking into the kdewebkit code that > bridged KIO with QNAM (since QtWebKit used QNAM). > > See for instance https://api.kde.org/frameworks/kio/html/ > classKIO_1_1CookieJar.html > It seems to be a QtNetwork compatible inferface for the KIO cookie jar. > Though the native API here might work too: > https://api.kde.org/4.x-api
Re: Join the Akademy 2018 talks committee!
On 30 Oct 2017 22:04, "Albert Astals Cid" wrote: Hi We are looking for people to join the Akademy 2018 Talks Committee. To be suitable all you need is to have attended Akademy previously, have a good idea of what the community is up to and have some spare time over the next few months. The committee comes up with some suggested themes in the Call for Papers and decides on the selection of talks from the submissions. So they are a very important part of making the conference a success. If you would like to be involved in this please let me know. Hello, I'd like to join the talks comitee this year. Best Marta
[ANNOUNCE] CMake 3.10.0-rc4 is now ready for testing
I am proud to announce the fourth CMake 3.10 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.10
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.10/release/3.10.html
Some of the more significant changes in CMake 3.10 are:
* The flang Fortran compiler is now supported, with compiler id
"Flang".
* Support for the MSVC ARM64 architecture was added. Visual Studio
2017 Update 4 and above offer an ARM64 toolchain.
* The "include_guard()" command was introduced to allow guarding
CMake scripts from being included more than once. The command
supports "DIRECTORY" and "GLOBAL" options to adjust the
corresponding include guard scope. If no options given, include
guard is similar to basic variable-based check.
* "FindMPI" received a major overhaul. It now features language specific
components, better Fortran support, and support for statically linked
MPI implementations.
* A "FindOpenACC" module was added to detect compiler support for
OpenACC. Currently only supports PGI, GNU and Cray compilers.
* The "FindOpenGL" module underwent numerous improvements. It has gained
support for GLVND and EGL on Linux. It now has import targets that
separate the OpenGL library and OpenGL contexts.
* The "GoogleTest" module gained a new command
"gtest_discover_tests()" implementing dynamic (build-time) test
discovery.
* When using "AUTOMOC" or "AUTOUIC", source files that are
"GENERATED" will be processed as well. They were ignored by
"AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071".
* A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest
script variable were added to specify a list of labels that should
be treated as subprojects by CDash. To use this value in both the
CTest module and the ctest command line Dashboard Client mode (e.g.
"ctest -S") set it in the "CTestConfig.cmake" config file.
* CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)",
configured by the "CPackFreeBSD" module.
* The CPack "DEB" generator, configured by the "CPackDeb" module,
was enabled on Windows. While not fully featured (due to the lack
of external UNIX tools) this will allow building basic cross-
platform Debian packages.
* The "cmake(1)" "-E" mode gained support for "sha1sum",
"sha224sum", "sha256sum", "sha384sum", and "sha512sum".
* The "file(GENERATE)" command now interprets relative paths given
to its "OUTPUT" and "INPUT" arguments with respect to the caller's
current binary and source directories, respectively. See policy
"CMP0070".
CMake 3.10 Release Notes
Changes made since CMake 3.9 include the following.
New Features
Platforms
-
* The flang Fortran compiler is now supported, with compiler id
"Flang".
* A new minimal platform file for "Midipix" was added.
* Support for the MSVC ARM64 architecture was added. Visual Studio
2017 Update 4 and above offer an ARM64 toolchain.
* Support for the IAR ARM Compiler was improved.
Generators
--
* The Makefile Generators and the "Ninja" generator learned to add
compiler launcher tools like ccache along with the compiler for the
"CUDA" language ("C" and "CXX" were supported previously). See the
"CMAKE__COMPILER_LAUNCHER" variable and
"_COMPILER_LAUNCHER" target property for details.
* The "CodeBlocks" extra generator learned to optionally exclude
files from outside the project root directory from the generated
project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable.
Commands
* The "cmake_host_system_information()" command learned more keys to
get information about the processor capabilities and the host OS
version.
* The "configure_file()" command learned to support indented "#
cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the
"#" character and the "cmakedefine"/"cmakedefine01" words are now
understood and preserved in the output.
* The "execute_process()" command gained a "RESULTS_VARIABLE" option
to collect a list of results from all children in a pipeline of
processes when multiple "COMMAND" arguments are given.
* The "include_guard()" command was introduced to allow guarding
CMake scripts from being included more than once. The command
supports "DIRECTORY" and "GLOBAL" options to adjust the
corresponding include guard scope. If no options given, include
guard is similar to basic variable-based check.
* The "string()" command learned a new "PREPEND" subcommand.
* The "string(TIMESTAMP)" command now supports "%A" for full weekday
name and "%B" for full month name.
Variables
-
* A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels
for all tests in a directory.
Properties
--
* A "_CPPCHECK" target property and supporting
"CMAKE__CPPCHECK" variable were introduced to tell the
Makefile Generators and the "Ninja" gener
