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.m...@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@qt-project.org https://lists.qt-project.org/listinfo/development
