[Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer]

> On 7 May 2024, at 17:51, Marc Mutz via Development <development at qt-project.org> wrote:
>> 
>> It doesn't change the technical roadblock: you *cannot* *move*
>> QDesktopServices. The best you can do for API is add a new one.
> 
> I'm pretty sure REMOVED_SINCE + an inline namespace around the Core 
> version would enable actual moving, but since I had read and understood 
> this argument before, I've implemented it under a different name now:
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/559958
> 
>> So I'd like an argument why it needs to be separate from QDesktopServices when
>> we already have that and cannot remove it until Qt 7.
> 
> It's technically separate, for BC reasons, but I wouldn't want to think 
> of it as new API. It's the old API, moved to QtCore. If you insist, I 
> can make it SC (REMOVED_SINCE + inline namespace).
> 
>> And I'd like an argument
>> why the API should be in QtCore, as opposed to QtNetwork (it's a browser after
>> all).
> 
> QtGui would gain a dependency on QtNetwork, or we'd need to duplicate 
> the implementation. QtCore is the common ancestor of both QtNetworkAuth 
> and QtGui. That's the technical argument.
> 
> The logical argument is that a) QUrl itself and b) QMimeTypeDatabase, 
> which co-determines which program to run on openUrl(), are both in 
> QtCore, so it makes sense that openUrl() would be, too.
> 
> Thanks,
> Marc


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.

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.

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.

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).


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.


Volker