ma 6. toukok. 2024 klo 11.05 Tor Arne Vestbø via Development (development@qt-project.org) kirjoitti: > > There’s some overlap here with the more modern features of intents, > activities, etc, which we are hoping to add proper APIs for at some point, so > I suggest not doing any public API changes as part of this. > > We can move the registration APIs to QtCore as private APIs, that > QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move the > URL handling part of the QPA plugins to QtCore under src/corelib/platform
Imho (eventually) moving the public header to QtCore would make sense, but as I understand it, there's some concerns and issues too. QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage at the user's discretion, and thus that currently won't force a Gui dependency. 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
