Also remove the jq package installation from the AppImage build script because
the package is included in the new Docker image (see nextcloud/docker-ci#231).
Signed-off-by: Michael Schuster <michael@schuster.ms>
For some reason the exported bitmaps in #2211 were not properly saved in the right
format for display by the NSIS installer system.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Uploading AppImage's to transfer.sh often fail and cause the CI to wait for
the 15 minutes timeout.
This new approach uses a bot user to create releases in a dedicated ci-builds
repository. Each PR (or master) will get a dedicated release with the AppImage
supplied as a release asset. Older assets will be deleted prior uploading the
recent build.
The bot will then (in case of a PR) create a comment in the PR, containing the
download link.
Home of the CI releases: https://github.com/nextcloud-desktop-bot/ci-builds/releases
Inspired by: https://github.com/nextcloud/android/blob/master/scripts/uploadArtifact.sh
Signed-off-by: Michael Schuster <michael@schuster.ms>
Now that we adjusted our protocol to follow the slightly updated server
API, let's make sure we don't try to talk to a server with an older API.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Previously we were using QCursor::pos() in the Linux case, which is a
fair heuristic except it will always be relative to the primary screen
and not the current screen. This explains why we had to adjust with the
virtual geometry.
In the Windows and Mac case we got the position out of QSystemTrayIcon
and that one was already relative to the current screen.
So now we use QCursor::pos(currentScreen()) which ensures we give the
coordinates relatively to the current screen also in the Linux case.
Since all platforms are now having that point in the same coordinate
system we don't need to mess around with the virtual geometry to
compensate.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Turns out that when we added a new e2e folder during sync, we were
passing the wrong path to the e2e object. We have several path
convention in the sync code, just happened to be the wrong one.
I still long for the day when we'll use the type system to deal with
paths. All those strings are error-prone.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Other clients seem to allow creating empty encrypted folders with no
metadata associated to them, so let's get ready to handle it. In case of
a 404 to get the metadata, we create an empty metadata payload and pass
it further down.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
