> On 6 May 2024, at 13:06, Juha Vuolle <juvuo...@gmail.com> wrote: > >> QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage >> at the user's discretion, and thus that currently won't force a Gui >> dependency. > > (Ah shoot. Correcting myself, in the new qtnetworkauth class we do > need to call QDesktopServices::openUrl() too to forward any unhandled > URLs.)
Which you can do through the private QtCore API that we add. Tor Arne > >> The concrete need for QtNetworkAuth at the moment is >> QDesktopServices::setUrlHandler() and >> QDesktopServices::unsetUrlHandler(). >> There is a new (Qt 6.8) class which needs to use these *) and that >> would create a module-level Gui dependency (unless using plugins or >> somesuch). >> >> Hence I'm wondering if, as a pragmatic pre-move, moving the >> implementation of those two functions behind a private header in >> QtCore (IIUC this is Tor Arne's proposal) would be >> sensible/acceptable? >> >> *) In order to be able to use custom-scheme and https-scheme redirect_uris >> >> Cheers, >> Juha >> >>> On 6 May 2024, at 09:51, Lars Knoll via Development >>> <development@qt-project.org> wrote: >>> >>> >>> >>> On 6 May 2024, at 09:02, Marc Mutz via Development >>> <development@qt-project.org> wrote: >>> >>> Hi, >>> >>> Juha is currently improving the OAuth implementation in QtNetworkAuth. >>> The protocol involves launching the system browser to get an access >>> code, in turn used to get access tokens with which services can then be >>> accessed. >>> >>> OAuth therefore requires a UI to run the browser in, but not necessarily >>> a _G_UI (the system browser could be lynx). Even if a CLI tool like a >>> mail fetcher, backup program, or VPN client will eventually launch >>> Firefox or Chrome, I think it's too much to ask to link to QtGui just to >>> do the equivalent of exec xdf-open <url>. >>> >>> >>> I’d agree with that. And there’s no way to do OAuth without launching a >>> browser during the authentication process. >>> >>> >>> I've looked at the implementation of openUrl(), and the only >>> Gui-dependency is on the platform helpers. The handler registration is >>> only using Core functionality. >>> >>> I would therefore propose to move the services code from Gui to Core >>> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui >>> dependency. >>> >>> After a quick look, I can see two ways to do that: >>> - keep the platform handling code in the platform helpers, incl. Gui >>> dependency, and only move the handler registration to Core >>> - move the platform url handlers out of the platform helpers into (a >>> plugin for) Core >>> >>> The first would enable users to write their own handlers w/o Gui >>> dependency, but has the disadvantage that the code behaves differently, >>> depending on whether QtGui is loaded or not. >>> >>> The second would be more work, but with consistently better user experience. >>> >>> Is there a reason other than history for the openUrl handlers to be in >>> the platform handlers? We have XDG-code in QtCore already (mime types), >>> so we should have all the information in Core already to implement the >>> functionality, should we not? >>> >>> >>> I believe the reason for this is mainly history. Moving this to Qt Core >>> makes sense IMO. >>> >>> I don’t think you need a separate plugin for Qt Core to implement this >>> though. I’m a bit unsure about the windows code, but on Linux and macOS >>> it’s simply launching ‘xdg-open’ or ‘open’. It would probably fit better to >>> simply follow the usual pattern for Qt Core with a _platform.cpp >>> implementation file. >>> >>> Cheers, >>> Lars >>> >>> >>> >>> Thanks, >>> Marc >>> >>> -- >>> Marc Mutz <marc.m...@qt.io> (he/his) >>> Principal Software Engineer >>> >>> The Qt Company >>> Erich-Thilo-Str. 10 12489 >>> Berlin, Germany >>> www.qt.io >>> >>> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen >>> Sitz der Gesellschaft: Berlin, >>> Registergericht: Amtsgericht Charlottenburg, >>> HRB 144331 B >>> -- >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development >>> >>> >>> -- >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development >>> >>> >>> -- >>> Development mailing list >>> Development@qt-project.org >>> https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
