On Tuesday 7 May 2024 22:32:47 GMT-7 Marc Mutz via Development wrote: > 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.
Why does it need that dependency? QtNetworkAuth should never open a window and start the browser on its own *anyway* without the application or library developer telling it to do so. And if they want it to do so, why can't that be the connect() line to QDesktopServices? > 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. I disagree. It needs to be a policy decision to do that, because the application may have reasons why it wants to do things differently. Though it needs to be easy too. > 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. That assumes we will have something. I am not convinced yet that any application exists where the three conditions I mentioned in another email are met. And besides, you've just said that the replacement may have a different API. That implies we haven't finished designing it yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
