> On 7 May 2024, at 12:51, Marc Mutz via Development > <development@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 <juvuo...@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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
