On 28/01/2026 18:14 UTC, Ben Cooksley wrote:
On Thu, Jan 29, 2026 at 3:42 AM Bernardo Negri
<[email protected]> wrote:
On 27/01/2026 15:50, Bernardo Negri wrote:
> Hello,
>
> I would like to start the incubation process for kio-onedrive[1]
and
> to seek a sponsor for this process. The KDE Invent issue to
track the
> incubation request is at
> <https://invent.kde.org/bernardogn/kio-onedrive/-/issues/20>.
>
> kio-onedrive is a kio worker that allows applications such as
Dolphin
> to access files stored on the user's Microsoft OneDrive account and
> the files stored in it, similarly to how kio-gdrive allows
Dolphin to
> access the user's Google Drive.
>
> The people committing to the project, as far as I know, would be
just
> me. However, a few KDE developers have expressed interest in the
past.
>
> I agree to follow the principles of the KDE manifesto.
>
> This project would also advance KDE's strategy to reach its
mission by
> "interoperating well with proprietary services."
>
> However, there may be one technical hiccup: right now, the project
> needs to be compiled with Ninja as the CMake generator, and with
Clang
> as the C++ compiler. When GCC 16 releases, it will be possible to
> compile kio-onedrive with GCC, but the requirement to use Ninja
as the
> CMake generator will stay for the foreseeable future. I do not
believe
> this is a too onerous requirement for distributions, I have
managed to
> make builds for Debian, OpenSUSE Tumbleweed, Arch Linux and
Fedora[2].
>
> Thank you,
>
> Bernardo
>
> [1] https://invent.kde.org/bernardogn/kio-onedrive/
>
> [2]
https://build.opensuse.org/package/show/home:bernardogn/kio-onedrive
>
Another thing I'd like to add: like most OAuth applications,
kio-onedrive needs a Client ID. Client IDs to access Microsoft
services
need to be registered at Azure with a Microsoft account. Right now,
kio-onedrive offers the build-time option to choose what Client ID to
use (but it can be changed after building by editing the kaccounts
file), and by default it uses a Client ID associated with my personal
Microsoft account.
I do not know what KDE's policy on such OAuth Client IDs is. I'd be
willing to change the default Client ID, but I think having a default
functional Client ID is useful.
We don't have a policy as such, however in the case of cloud provider
services it is usually beneficial if you use a Client ID belonging to
an application registered by KDE.
This helps if permissions or other information associated with the
application need to be changed in the future, and in the case of
Microsoft specifically, also allows for easier use with Enterprise
setups as we've obtained the appropriate registrations with Microsoft
for that (already done for Kontact)
Thanks for the suggestion. The Kontact client id works fine, since it
also allowed to use the Files.ReadWrite.All scope. However, if
Sharepoint support is ever properly implemented, then the Kontact app
registration will also need to be updated.
For now, I think I will wait for Incubation to be complete before
switching to the Kontact client id, as using the Kontact client id is
using KDE branding.
Cheers,
Bernardo
Thanks,
Ben
Thanks,
Bernardo
