[Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

ma 6. toukok. 2024 klo 11.05 Tor Arne Vestbø via Development
(development at 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 at qt-project.org> wrote:
>
>
>
> On 6 May 2024, at 09:02, Marc Mutz via Development <development at 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.mutz at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> --
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development