[Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø]

> On 6 May 2024, at 13:06, Juha Vuolle <juvuolle at 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 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