[Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz]

On 07.05.24 18:46, Volker Hilsheimer wrote:
> In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a browser” is not true for every possible call of the QDesktopServices API.

We need something _now_ for QtNetworkAuth, though. What do these options mean for OAuth support in QtNetworkAuth (my attempt at an analysis below).

> However, whether a new QCoreDesktopServices namespace becomes public QtCore API or not in Qt 6.8 is somewhat irrelevant as long as it doesn’t do anything on any platform. The QPA infrastructure in general, and the implementations of QPlatformServices in particular is -as of now - not loaded by an application that doesn’t use QtGui. And we haven’t even started discussing if and how we’d like to make that happen. I do not anticipate that we will get that infrastructure into Qt Core in time for the Qt 6.8 feature freeze in three weeks; while it’s probably not rocket science to write the code, there are evidently too many disagreements on (and probably several devils in) the details.

We have a template for this: the permission API. It's a) in QtCore and also highly platform-dependent. I also, honestly, don't see the extraction of the non-Gui code from the QPAs into some QtCore files or plugin as something subject to feature freeze. It's kinda cleanup under the hood. Certainly we can't argue that moving the implementation as private API is ok post-FF, but moving the interface as public API now and moving the implementation as private implementation detail post-FF is not, can we?

> I can see two options:
> 
> 1) we leave it entirely to the application to implement a Core-only equivalent of QDesktopServices
> 
> Not fun, but not impossible either, esp given that whoever needs this can take our existing code. We could even have that code in an example, at least for some platforms. This doesn’t invalidate the improved OAuth support in 6.8, esp if we assume that the vast majority of users today will use Qt Gui anyway, and that Qt Core only use cases are rare enough to deal with the alternative.

AFAICT, this means one of the following:

a) that we have to postpone QtNetworkAuth until new QtCore API is added, 
provided that any future intents/activities API actually pertains to and 
supports implementation of what OAuth needs. Danger of "the perfect is 
the enemy of the good" here.

b) that QtNetworkAuth gets the undesired QtGui dependency, which becomes 
stale once new Core API is merged, but then has to be carried along for 
BC reasons.

c) that the user has to connect the pieces of the flow together 
manually. The whole point of the code there is to _implement_ the flow, 
though. That involves not only calling openUrl(), but also installing 
URL handlers. If the user has to connect all the dots manually, because 
parts of it are in QtGui, then a large percentage of the value of the 
implementation is lost. Plus, we'd set up the user for failure once we 
come up with a new API to replace QDS: he will need to rewrite his 
connect-the-dots code, against a very-probably changed QtNetworkAuth 
API, too. If we continue to keep the flow implementation internal to 
QtNetworkAuth as much as possible (and make more possible), then the 
user of QtNetworkAuth falls into the pit of success.

Which of those should we implement, do you think? I don't like any of them.

> 2) we put a copy of our implementations into Qt Network, without any public API
> 
> It could (but doesn’t have to) be a Qt Network specific plugin, and if that plugin exists then we use the implementation in it automatically whenever we’d emit QOAuth2AuthorizationCodeFlow::authorizeWithBrowser. We could add a property of QOAuth2AuthorizationCodeFlow to “useDefaultBrowser” to enable that (and one future day, setting that property will automatically make it go through our new public API instead).
> 
> Option 2 is not a lot of work, with no impact on public API at this point, while enabling a good out-of-the-box usability of the new OAuth support. The drawback is that we have a duplicate a bunch of code (or find a way to build the relevant sources twice), the most of which seems to be in the Xcb QPA plugin (and not all of that might be relevant if we want to support a QtCore-only-app-on-GUI-less-system scenario).

What good could possibly come out of copying that code to QtNetwork? A 
QtNetwork dependency on QtGui? If not that, we'd need to split the 
implementation into Gui and non-Gui parts, and if we do that, we might 
as well put it into Core, where it belongs.

> If I was paying y’all’s salary, then I’d strongly suggest to go with option 1, and maybe follow up with Option 2 for 6.9, while we take the time it takes to figure out how to properly wrap intents etc into a cross-platform abstraction.

I don't see (1) solving anything for QtNetworkAuth and (2) as being 
roughly equivalent to putting the code into QtCore.

I'd like an option that actually solves for the needs of QtNetworkAuth.

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