On Sat, Jan 31, 2026 at 8:10 AM Bernardo Negri <[email protected]> wrote:
> 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. > It would be preferable if it used it's own Client ID - once incubated please file a Sysadmin ticket and we'll set that up. That keeps things in the spirit of what is intended usage by Microsoft (and expected by Enterprise Administrators) > >> Cheers, >> >> Bernardo >> >> > Thanks, > Ben > > Thanks, > > Bernardo > Cheers, Ben
