[Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø]

> On 7 May 2024, at 12:51, Marc Mutz via Development <development at qt-project.org> wrote:
> 
> On 06.05.24 13:08, Tor Arne Vestbø via Development wrote:
>> 
>> 
>>> 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.
> 
> AFAIU, it's the user that needs to make a connection to openUrl() from 
> an OAuth signal: 
> https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28


Looking at the API, does the user even need to connect authorizeWithBrowser to openUrl? Couldn’t QOAuth2AuthorizationCodeFlow do that automatically?

> 
> So, no, private-only API won't cut it.

An alternative that wouldn’t require the QtCore move is to expose an openChallengeUrl on QOAuth2AuthorizationCodeFlow

> Honestly, I don't understand the push-back for the move. It seems only 
> logical to me: QUrl is in QtCore, so IMHO, it's only logical to have 
> QUrl _handlers_ in QtCore, too. And in other emails, I showed use-cases 
> of CLI programs that need openUrl(), but not the rest of QtGui.
> 
> So, we have use-cases and we seem to have no technical reason to not 
> move the code (if we can provide it as private API, there can't be many).

As I mentioned earlier, twice I think now, there is overlap to intents/activities, which are also URL based. If we want to build a Qt API for this, it would make sense to not propagate the (legacy) QDesktopServices openUrl/urlHandler APIs further.

Tor Arne