GitLab

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Connect to the new FetchJob signal. It allows us to use new
connect syntax, and it's faster, because we don't have to do
any QMap lookups.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

... and we still depend on 5.7 here.

With Graph API 2.0 apps can only see friends that also use the same app.
This is not very useful, since for most users the birthday calendar would
be mostly empty. Luckily Facebook provides an iCal with all friends'
birthdays, so we use a bit of cookie magic to download user's Facebook
Events page, parse the iCal URL from it and then fetch the iCal with all
birthdays. Yay for us.

We use a dedicated QtWebEngineProfile for each resource instance and
for each profile we store all cookies that Facebook creates during
login. This will allow us to query the webpage later to sync birthdays.
It also allows us to inject the cookies back into the profile before
refreshing token so that user does not have to re-enter their password
every time.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

The resources creates a set of calendars for events that the user is
attending, maybe attending, declined, not responded yet and for friends'
birthdays. Each calendar contains respective Facebook events.

Facebook does not seem to have any form of incremental query API so we
always fetch all events, which is a bit unfortunate, but I don't see
how else we could handle this without assuming too much about FB API
behavior.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

We don't want to make them dbus accessible

Differential Revision: https://phabricator.kde.org/D6205

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

the vcarddir resources uses the generated source from settingsdialog.ui
of singlefileresource; make sure it is already generated

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"