Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

On 8 May 2024, at 13:14, Juha Vuolle  wrote:

Hi, sorry for just kind of resetting the thread, but we had a quick
discussion with Marc and Tor Arne.

There's an additional constraint that, at least on iOS/macOS, that the
OS/platform callback mechanisms depend on UI libraries (AppKit and
UIKit).
While making that work in QtCore could *maybe* technically be
possible, it'd just add to the effort and risk we'd be talking about
here.

Hence a concrete suggestion with a few specific questions.

Thing 1) In Qt 6.8 we'll add a QtGui dependency to QtNetworkAuth
module. With this the new Qt 6.8 features will work.
Thing 2) This QtGui dependency will be behind a Qt feature flag.
Thing 3) Later in Qt 6.9+, if the three QDS functionalities become
available via QtCore, then QtNetworkAuth drops the QtGui dependency.
IIUC dropping a private linkage shouldn't cause "transitive" problems.
The main questions:
Question 1) Do we foresee problems on introducing a Gui dependency to
QtNetworkAuth?
Question 2) Do we foresee problems in possibly later dropping the Gui
dependency?


Given all the information, that approach sounds sensible.

Adding Qt Gui as a dependency to QtNetworkAuth shouldn’t be a problem, 
especially if it’s possible to opt out, and as long as it’s documented in the 
ChangeLog that application using QtNetworkAuth now need to deploy Qt Gui as 
well. We added that kind of dependency when we linked Qt TextToSpeech against 
Qt Multimedia (see discussion at 
https://lists.qt-project.org/pipermail/development/2023-January/043562.html).

And I can’t foresee a problem with later on dropping that dependency.

One thing to consider is whether you need a QGuiApplication instance for things 
to work. If things can’t work across platforms if the application only gives 
you a QCoreApplication instance, then it might be possible to add some virtual 
function(s) to QCoreApplicationPrivate that you can call from QtNetworkAuth to 
enable the implicit OAuth flow handling only if GUI is alive. Then things will 
degrade gracefully if QtGui is not initialized. We have some similar approaches 
to trigger Qt Widgets specific behaviors from Qt Gui classes 
(QGuiApplicationPrivate::closeAllPopups, for instance, or even 
createActionPrivate/createShortcutPrivate).

Volker



ke 8. toukok. 2024 klo 12.51 Volker Hilsheimer via Development
(development@qt-project.org) kirjoitti:



On 8 May 2024, at 07:32, Marc Mutz via Development  
wrote:

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



I question that. QtNetworkAuth’s 
QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
by users, as long as they are either willing to use Qt GUI, or to write their 
own handler code (possibly inspired but what we have in Qt Gui).


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?


The point of feature freeze is that we start stabilizing the release.

Moving large chunks of code around, while not forbidden explicitly, doesn’t 
move us to that end.


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 

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

Hi, sorry for just kind of resetting the thread, but we had a quick
discussion with Marc and Tor Arne.

There's an additional constraint that, at least on iOS/macOS, that the
OS/platform callback mechanisms depend on UI libraries (AppKit and
UIKit).
While making that work in QtCore could *maybe* technically be
possible, it'd just add to the effort and risk we'd be talking about
here.

Hence a concrete suggestion with a few specific questions.

Thing 1) In Qt 6.8 we'll add a QtGui dependency to QtNetworkAuth
module. With this the new Qt 6.8 features will work.
Thing 2) This QtGui dependency will be behind a Qt feature flag.
Thing 3) Later in Qt 6.9+, if the three QDS functionalities become
available via QtCore, then QtNetworkAuth drops the QtGui dependency.
IIUC dropping a private linkage shouldn't cause "transitive" problems.
The main questions:
Question 1) Do we foresee problems on introducing a Gui dependency to
QtNetworkAuth?
Question 2) Do we foresee problems in possibly later dropping the Gui
dependency?

ke 8. toukok. 2024 klo 12.51 Volker Hilsheimer via Development
(development@qt-project.org) kirjoitti:
>
>
>
> On 8 May 2024, at 07:32, Marc Mutz via Development 
>  wrote:
>
> 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).
>
>
>
> I question that. QtNetworkAuth’s 
> QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
> by users, as long as they are either willing to use Qt GUI, or to write their 
> own handler code (possibly inspired but what we have in Qt Gui).
>
>
> 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?
>
>
> The point of feature freeze is that we start stabilizing the release.
>
> Moving large chunks of code around, while not forbidden explicitly, doesn’t 
> move us to that end.
>
>
> 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.
>
>
>
> Depending on Qt Gui might not be perfect, but it’s good enough for the vast 
> majority of users.
>
>
> 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.
>
>
> QtNetworkAuth doesn’t have to link against Qt Gui. The application does. Qt 
> NetworkAuth emits a signal, the application handles that.
>
> Or do I misinterpret what 
> https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28
>   (which is the example you referred to a few days ago) is doing and how that 
> relates to how things should be done in the future with new and improved Qt 
> NetworkAuth?
>
> Maybe it’s time to point at what new and improved Qt NetworkAuth we are 
> talking about… maybe it’s 
> https://codereview.qt-project.org/c/qt/qtnetworkauth/+/556023?
>

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

On 8 May 2024, at 07:32, Marc Mutz via Development  
wrote:

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


I question that. QtNetworkAuth’s 
QOAuth2AuthorizationCodeFlow::authorizeWithBrowser signal is perfectly usable 
by users, as long as they are either willing to use Qt GUI, or to write their 
own handler code (possibly inspired but what we have in Qt Gui).


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?

The point of feature freeze is that we start stabilizing the release.

Moving large chunks of code around, while not forbidden explicitly, doesn’t 
move us to that end.


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.


Depending on Qt Gui might not be perfect, but it’s good enough for the vast 
majority of users.


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.

QtNetworkAuth doesn’t have to link against Qt Gui. The application does. Qt 
NetworkAuth emits a signal, the application handles that.

Or do I misinterpret what 
https://code.qt.io/cgit/qt/qtnetworkauth.git/tree/examples/oauth/redditclient/redditwrapper.cpp#n28
  (which is the example you referred to a few days ago) is doing and how that 
relates to how things should be done in the future with new and improved Qt 
NetworkAuth?

Maybe it’s time to point at what new and improved Qt NetworkAuth we are talking 
about… maybe it’s https://codereview.qt-project.org/c/qt/qtnetworkauth/+/556023?


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.


Thanks for finally sharing that bit of information :)

Up to now and based on the discussion here, my assumption was not that we 
replace the responsibility of the application developer (as exemplified by the 
quoted redditclient example) with a baked-in workflow implementation that 
handles redirects etc.


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 

Re: [Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø via Development]

> On 8 May 2024, at 07:32, Marc Mutz via Development 
>  wrote:
> 
> I'd like an option that actually solves for the needs of QtNetworkAuth.

1. Move the plumbing of the URL handling to private APIs in QtCore, used by 
QDesktopServices
2a. Add a helper QOAuth2AuthorizationCodeFlow::openChallengeUrl function that 
uses the QtCore private api
2b. Have QOAuth2AuthorizationCodeFlow automatically open the browser via the 
QtCore private API

No public API changes needed to QDesktopServices needed, which means we’re not 
blocking the QtNetworkAuth work on the work required to research 
activities/intents APIs (which is not scheduled for 6.8).

Tor Arne

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

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 

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Tuesday 7 May 2024 10:50:09 GMT-7 Lars Knoll via Development wrote:
> There could also be use cases where you have split your app into two parts,
> a UI running in one process and a backend running in another one. The
> backend doesn’t link against any GUI libraries, but might need to launch an
> OAuth flow in response to something that’s been triggered by the UI. And
> there could be many reasons why you’d want a process separation, security
> being one of them.
> 
> So I do believe there are valid use cases for opening a browser window from
> a process that does not link against a GUI library. Given that the
> implementation doesn’t require anything UI specific neither I don’t see why
> we shouldn’t have it in Qt Core.

I agree with the conclusion. But your premise is talking about it being a 
tightly-coupled UI and non-UI process components. So the non-UI component 
doesn't want to use QCoreDesktopServices::openUrl in the first place: it wants 
to communicate with its UI component through whichever communication mechanism 
it has established.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Lars Knoll via Development]

> On 7 May 2024, at 19:15, Thiago Macieira  wrote:
> 
> On Tuesday 7 May 2024 10:03:21 GMT-7 Thiago Macieira wrote:
>> So I want to know of a use-case where all of the following are true:
>> * application is GUI-less (i.e., is a background service)
>> * application has no GUI counterpart
>> * application is definitely running in a GUI environment

One example I’ve seen are installation scripts that you run from the command 
line that need some permissions and launch a browser to get them. Pretty much 
the OAuth case mentioned here.
> 
> Rethinking a little here, if we drill d own one level it may make sense. 
> Replace "application" with "library":
> 
> One may want to make a library that has no GUI dependency and implements some 
> network service. Therefore, they don't want to link to QtGui for 
> QDesktopServices. If the functionality is in QtCore, then they could request 
> the browser if the application is GUI.
> 
> The problem is that said library needs a fallback if the application is *not* 
> GUI. Moreover, I'd question the automatic launching of a browser as part of 
> this library's behaviour. A better design would be for it to emit a signal 
> indicating it requires something to happen and then to let the application or 
> a wrapping library to make a policy decision on what to do.

There could also be use cases where you have split your app into two parts, a 
UI running in one process and a backend running in another one. The backend 
doesn’t link against any GUI libraries, but might need to launch an OAuth flow 
in response to something that’s been triggered by the UI. And there could be 
many reasons why you’d want a process separation, security being one of them.

So I do believe there are valid use cases for opening a browser window from a 
process that does not link against a GUI library. Given that the implementation 
doesn’t require anything UI specific neither I don’t see why we shouldn’t have 
it in Qt Core.

Cheers,
Lars

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Tuesday 7 May 2024 10:03:21 GMT-7 Thiago Macieira wrote:
> So I want to know of a use-case where all of the following are true:
> * application is GUI-less (i.e., is a background service)
> * application has no GUI counterpart
> * application is definitely running in a GUI environment

Rethinking a little here, if we drill d own one level it may make sense. 
Replace "application" with "library":

One may want to make a library that has no GUI dependency and implements some 
network service. Therefore, they don't want to link to QtGui for 
QDesktopServices. If the functionality is in QtCore, then they could request 
the browser if the application is GUI.

The problem is that said library needs a fallback if the application is *not* 
GUI. Moreover, I'd question the automatic launching of a browser as part of 
this library's behaviour. A better design would be for it to emit a signal 
indicating it requires something to happen and then to let the application or 
a wrapping library to make a policy decision on what to do.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Tuesday 7 May 2024 08:51:03 GMT-7 Marc Mutz via Development wrote:
> > I'd like to see some GUI-less Qt applications perform those services, but
> > then they are highly limited on how to start the browser in the first
> > place. Anything beyond "print URL to stdout" may not be acceptable at
> > all, as they may be running *in* a GUI-less environment, such as my
> > emailproxy case.
> Given that std C++ still has no network classes, and Boost.Async is ...
> an acquired taste, let's leave it at that ... I'd like to think that
> QtCore+QtNetwork programs still have their place. At least I wouldn't
> want to be the one ruling them out for our users.

I agree with you there.

But my point stands: GUI-less Qt applications may have no way of launching the 
browser in the first place because there is no GUI. If this is running as a 
service in the background, it needs communicate with its GUI front-end to 
perform the necessary actions.

So I want to know of a use-case where all of the following are true:
* application is GUI-less (i.e., is a background service)
* application has no GUI counterpart
* application is definitely running in a GUI environment

An example of GUI-less, networking Qt applications are the Akonadi agents. 
Those end up linking to everything and the kitchen sink, so even QtMultimedia 
is loaded, but they are effectively GUI-less.

Despite being a background service, Akonadi is actually only launched in GUI 
environments.

However, Akonadi has built-in GUI counterpart mechanisms, so there is no need 
for background services to attempt to launch browsers or open windows.

> > 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:

The rules for macOS are simple:
* keep the symbols that are in QtGui right now in QtGui
* do not add the same symbols to any other library

If you can find a way such that we are source-compatible but with different 
symbols, then we can effectively move them.

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

Not necessarily. We can have a private hook like the one you implemented, such 
that the dependency isn't there. My request was about front-end API.

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

But the same can be said about fetching data from the network: it's all in 
QtNetwork.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Tuesday 7 May 2024 08:32:35 GMT-7 Marc Mutz via Development wrote:
> If and when intents/activities replace openUrl(), QtNetworkAuth will
> have to be ported, QtCore move or not, public API or not.

Would that leave an API in QtCore that isn't necessary or is duplicated?

Please design an API now that will work with intents/activities.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Volker Hilsheimer via Development]

> On 7 May 2024, at 17:51, Marc Mutz via Development 
>  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

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

On 07.05.24 16:30, Thiago Macieira wrote:
> On Monday 6 May 2024 23:08:07 GMT-7 Marc Mutz via Development wrote:
[...]
>> I'm currently fighting an older version of openfortifyvpn (CLI on Linux)
>> which cannot, yet, spin up the browser. Newer versions are reported to
>> be able to, so there you have your use case. Plus mail fetchers, backup
>> clients, basically everything that needs to authenticate with a web
>> service of any kind needs OAuth support these days, and we can't ask all
>> of them to embed QtWebEngine. Speaking with my security hat on, even the
>> QtGui dependency would be a complete no-no for such applications: One
>> should never, ever, link to libraries one doesn't need, as that does
>> nothing but increase the amount of potentially exploitable code in the
>> process' address space.
> 
> That's a fair argument.
> 
> I don't think those are going to be GUI-less Qt applications, though. That
> number I still believe to be zero. They may be GUI Qt applications, such as
> system tray services. A good example would be the VPN: you need a way to turn
> it on and off (on Linux ,that's already implemented and is called
> NetworkManager).
> 
> I'd like to see some GUI-less Qt applications perform those services, but then
> they are highly limited on how to start the browser in the first place.
> Anything beyond "print URL to stdout" may not be acceptable at all, as they
> may be running *in* a GUI-less environment, such as my emailproxy case.

Given that std C++ still has no network classes, and Boost.Async is ... 
an acquired taste, let's leave it at that ... I'd like to think that 
QtCore+QtNetwork programs still have their place. At least I wouldn't 
want to be the one ruling them out for our users.

>>> I suggest having a background hook that QPA registers with QtCore so that
>>> QtNetwork can use to launch the browser if QPA has been loaded, but shall
>>> fail if not.
>>
>> That doesn't solve the openfortifypn use-case, though. We can debate
>> whether it's a valid one, but I think I just did.
> 
> 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

-- 
Marc Mutz  (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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

On 07.05.24 14:58, Tor Arne Vestbø wrote:
[...]
>> 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.

In which way are we propagating the API further? We're just moving it 
from one library to the next. And QtNetworkAuth is already using it.

Do you have some timeline for intents/activities? Because the improved 
OAuth support is ready _now_, for 6.8., if it weren't for the 
undesirable QtGui dependency.

If and when intents/activities replace openUrl(), QtNetworkAuth will 
have to be ported, QtCore move or not, public API or not.

Thanks,
Marc

-- 
Marc Mutz  (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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Monday 6 May 2024 23:08:07 GMT-7 Marc Mutz via Development wrote:
> Such applications wouldn't use QNetworkAuth, though, because returning
> access codes by cookie isn't one of the standardized mechanisms, and
> therefore not implemented in QNetworkAuth. I can see this bahviour every
> week when Thunderbird or the Linux "native" Teams client have kicked me
> out and ask for the password again. Both don't spin the system browser,
> and so I need to copy my password from Firefox to their own shitty
> dialogs manually each time. Very annoying, but that's precisely _not_
> what the spec asks for, either.

BTW, the other need I have is Microsoft's email service. And for that, I 
highly recommend https://github.com/simonrob/email-oauth2-proxy. I've attached 
my GUIless .service file. Whenever I need to re-authenticate, I look up the 
journal logs and click the link that shows up there.

I agree this is not the best UX for most people. It works for me and I may 
guess some of you here.

> I'm currently fighting an older version of openfortifyvpn (CLI on Linux)
> which cannot, yet, spin up the browser. Newer versions are reported to
> be able to, so there you have your use case. Plus mail fetchers, backup
> clients, basically everything that needs to authenticate with a web
> service of any kind needs OAuth support these days, and we can't ask all
> of them to embed QtWebEngine. Speaking with my security hat on, even the
> QtGui dependency would be a complete no-no for such applications: One
> should never, ever, link to libraries one doesn't need, as that does
> nothing but increase the amount of potentially exploitable code in the
> process' address space.

That's a fair argument.

I don't think those are going to be GUI-less Qt applications, though. That 
number I still believe to be zero. They may be GUI Qt applications, such as 
system tray services. A good example would be the VPN: you need a way to turn 
it on and off (on Linux ,that's already implemented and is called 
NetworkManager).

I'd like to see some GUI-less Qt applications perform those services, but then 
they are highly limited on how to start the browser in the first place. 
Anything beyond "print URL to stdout" may not be acceptable at all, as they 
may be running *in* a GUI-less environment, such as my emailproxy case.

> > I suggest having a background hook that QPA registers with QtCore so that
> > QtNetwork can use to launch the browser if QPA has been loaded, but shall
> > fail if not.
> 
> That doesn't solve the openfortifypn use-case, though. We can debate
> whether it's a valid one, but I think I just did.

It doesn't change the technical roadblock: you *cannot* *move* 
QDesktopServices. The best you can do for API is add a new one.

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. And I'd like an argument 
why the API should be in QtCore, as opposed to QtNetwork (it's a browser after 
all).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Cloud Engineering
# -*- conf -*-
[Unit]
Description=Service for the Microsoft365 OAuth2 proxying
ConditionPathExists=/etc/emailproxy/emailproxy.config

[Service]
PrivateDevices=yes
PrivateTmp=yes
ProtectHome=yes
ProtectProc=noaccess
ProtectSystem=strict
RestrictAddressFamilies=AF_UNIX AF_INET
UMask=077

ConfigurationDirectory=emailproxy
CacheDirectory=emailproxy
CacheDirectoryMode=0700

ExecStart=python3 /usr/local/bin/emailproxy.py --no-gui --local-server-auth --config-file ${CONFIGURATION_DIRECTORY}/emailproxy.config --cache-store ${CACHE_DIRECTORY}/auth-cache
Group=emailproxy
User=emailproxy


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø via Development]

> On 7 May 2024, at 12:51, Marc Mutz via Development 
>  wrote:
> 
> On 06.05.24 13:08, Tor Arne Vestbø via Development wrote:
>> 
>> 
>>> On 6 May 2024, at 13:06, Juha Vuolle  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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

On 06.05.24 13:08, Tor Arne Vestbø via Development wrote:
> 
> 
>> On 6 May 2024, at 13:06, Juha Vuolle  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

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

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

So, if this boils down to private vs. public API: Why keep it private? 
It's not new API, it's just renamed for BC reasons.

Thanks,
Marc

-- 
Marc Mutz  (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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

On 06.05.24 17:18, Thiago Macieira wrote:
> On Monday 6 May 2024 00:02:58 GMT-7 Marc Mutz via Development wrote:
>> Juha is currently improving the OAuth implementation in QtNetworkAuth.
>> The protocol involves launching the system browser to get an access
>> code, in turn used to get access tokens with which services can then be
>> accessed.
>>
>> OAuth therefore requires a UI to run the browser in, but not necessarily
>> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
>> mail fetcher, backup program, or VPN client will eventually launch
>> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
>> do the equivalent of exec xdf-open .
> 
> That's true, but for such a restricted context that it's a negligible case.
> 
> The chance that anyone who is using Qt has lynx or links as a web browser is
> indistinguishable from zero. And the chance that the non-GUI browser they're
> using is useful to perform an OAuth authentication is smaller than even that.

I agree about Lynx, but the main point was another.

> Further, my experience with OAuth is that sometimes not even an external
> browser suffices. Of the two cases I have a need for so far, one of them (Palo
> Alto Networks' VPN product called "GlobalProtect") requires a full web engine
> because the information that is required is stored in a cookie that is only
> available in the response header.

Such applications wouldn't use QNetworkAuth, though, because returning 
access codes by cookie isn't one of the standardized mechanisms, and 
therefore not implemented in QNetworkAuth. I can see this bahviour every 
week when Thunderbird or the Linux "native" Teams client have kicked me 
out and ask for the password again. Both don't spin the system browser, 
and so I need to copy my password from Firefox to their own shitty 
dialogs manually each time. Very annoying, but that's precisely _not_ 
what the spec asks for, either.

> So, no, I don't think this should move. I don't think there's any situation
> where *any* user is going to benefit from this in a non-GUI environment. A
> class called QDesktopServices is really just about GUI desktops. Further,
> QPlatformIntegration *IS* QPA. You can't move that class to QtCore.

I'm currently fighting an older version of openfortifyvpn (CLI on Linux) 
which cannot, yet, spin up the browser. Newer versions are reported to 
be able to, so there you have your use case. Plus mail fetchers, backup 
clients, basically everything that needs to authenticate with a web 
service of any kind needs OAuth support these days, and we can't ask all 
of them to embed QtWebEngine. Speaking with my security hat on, even the 
QtGui dependency would be a complete no-no for such applications: One 
should never, ever, link to libraries one doesn't need, as that does 
nothing but increase the amount of potentially exploitable code in the 
process' address space.

> I suggest having a background hook that QPA registers with QtCore so that
> QtNetwork can use to launch the browser if QPA has been loaded, but shall fail
> if not.

That doesn't solve the openfortifypn use-case, though. We can debate 
whether it's a valid one, but I think I just did.

Thanks,
Marc

-- 
Marc Mutz  (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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Monday 6 May 2024 11:48:31 GMT-7 Allan Sandfeld Jensen wrote:
> Out of purely academic interest, how would I go about searching for those
> problems? Would I be lucky enough they would all be conviently gathered in a
> JIRA ticket?

Unfortunately, no. But if you search JIRA for Qt 4.x-time QXmlStream problems, 
you may find some of them.

The issue is that there are two platforms where symbol resolution at runtime 
is tied to the library they were found in at link time (so-called "two-level 
symbol resolution"). Therefore, for those two platforms, whatever we do, to 
keep BC, we must retain QDesktopServices in QtGui.

On one of those two platforms, duplicating the symbols in the libraries is not 
a problem; but for the other one it is, therefore we must rename them when 
importing to QtCore. That's why we had this:
https://github.com/qt/qt/blob/4.8/src/corelib/xml/qxmlstream.h#L100-L114

For QXmlStream classes, this was a big problem because one had objects of the 
types being renamed, so this caused cascading mangling changes in user code 
wherever they used our classes. This is the same BC break as libstdc++ did 
with std::__cxx11::basic_string. For QDesktopServices, at least there is no 
object and therefore no one is expecting to have functions with it as part of 
the mangled name.

Those two platforms are:
 - Darwin (macOS, iOS, etc.)
 - Windows

So not insignificant. And moreover, the two platforms where no one EVER runs 
without a GUI.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Allan Sandfeld Jensen]

On Monday 6 May 2024 17:21:14 CEST Thiago Macieira wrote:
> On Monday 6 May 2024 03:31:46 GMT-7 Allan Sandfeld Jensen wrote:
> > Is there any problem in moving the class all the way if we preserve the
> > headers under both QtGui and QtCore?
> 
> Yes. The last time we did that (moving the XML stream classes from QtXml to
> QtCore), we found a lot of problems and promised not to do it again.
> 
> So QDesktopServices can't be moved. You can add a new class to QtCore.

Out of purely academic interest, how would I go about searching for those 
problems? Would I be lucky enough they would all be conviently gathered in a 
JIRA ticket?

Best regards
Allan


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Monday 6 May 2024 03:31:46 GMT-7 Allan Sandfeld Jensen wrote:
> Is there any problem in moving the class all the way if we preserve the
> headers under both QtGui and QtCore?

Yes. The last time we did that (moving the XML stream classes from QtXml to 
QtCore), we found a lot of problems and promised not to do it again.

So QDesktopServices can't be moved. You can add a new class to QtCore.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Thiago Macieira]

On Monday 6 May 2024 00:02:58 GMT-7 Marc Mutz via Development wrote:
> Juha is currently improving the OAuth implementation in QtNetworkAuth.
> The protocol involves launching the system browser to get an access
> code, in turn used to get access tokens with which services can then be
> accessed.
> 
> OAuth therefore requires a UI to run the browser in, but not necessarily
> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
> mail fetcher, backup program, or VPN client will eventually launch
> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
> do the equivalent of exec xdf-open .

That's true, but for such a restricted context that it's a negligible case.

The chance that anyone who is using Qt has lynx or links as a web browser is 
indistinguishable from zero. And the chance that the non-GUI browser they're 
using is useful to perform an OAuth authentication is smaller than even that.

Further, my experience with OAuth is that sometimes not even an external 
browser suffices. Of the two cases I have a need for so far, one of them (Palo 
Alto Networks' VPN product called "GlobalProtect") requires a full web engine 
because the information that is required is stored in a cookie that is only 
available in the response header.

So, no, I don't think this should move. I don't think there's any situation 
where *any* user is going to benefit from this in a non-GUI environment. A 
class called QDesktopServices is really just about GUI desktops. Further, 
QPlatformIntegration *IS* QPA. You can't move that class to QtCore.

I suggest having a background hook that QPA registers with QtCore so that 
QtNetwork can use to launch the browser if QPA has been loaded, but shall fail 
if not.

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

Re: [Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø via Development]

> On 6 May 2024, at 13:06, Juha Vuolle  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.

Tor Arne 

> 
>> The concrete need for QtNetworkAuth at the moment is
>> QDesktopServices::setUrlHandler() and
>> QDesktopServices::unsetUrlHandler().
>> There is a new (Qt 6.8) class which needs to use these *) and that
>> would create a module-level Gui dependency (unless using plugins or
>> somesuch).
>> 
>> Hence I'm wondering if, as a pragmatic pre-move, moving the
>> implementation of those two functions behind a private header in
>> QtCore (IIUC this is Tor Arne's proposal) would be
>> sensible/acceptable?
>> 
>> *) In order to be able to use custom-scheme and https-scheme redirect_uris
>> 
>> Cheers,
>> Juha
>> 
>>> On 6 May 2024, at 09:51, Lars Knoll via Development 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On 6 May 2024, at 09:02, Marc Mutz via Development 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> Juha is currently improving the OAuth implementation in QtNetworkAuth.
>>> The protocol involves launching the system browser to get an access
>>> code, in turn used to get access tokens with which services can then be
>>> accessed.
>>> 
>>> OAuth therefore requires a UI to run the browser in, but not necessarily
>>> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
>>> mail fetcher, backup program, or VPN client will eventually launch
>>> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
>>> do the equivalent of exec xdf-open .
>>> 
>>> 
>>> I’d agree with that. And there’s no way to do OAuth without launching a 
>>> browser during the authentication process.
>>> 
>>> 
>>> I've looked at the implementation of openUrl(), and the only
>>> Gui-dependency is on the platform helpers. The handler registration is
>>> only using Core functionality.
>>> 
>>> I would therefore propose to move the services code from Gui to Core
>>> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
>>> dependency.
>>> 
>>> After a quick look, I can see two ways to do that:
>>> - keep the platform handling code in the platform helpers, incl. Gui
>>> dependency, and only move the handler registration to Core
>>> - move the platform url handlers out of the platform helpers into (a
>>> plugin for) Core
>>> 
>>> The first would enable users to write their own handlers w/o Gui
>>> dependency, but has the disadvantage that the code behaves differently,
>>> depending on whether QtGui is loaded or not.
>>> 
>>> The second would be more work, but with consistently better user experience.
>>> 
>>> Is there a reason other than history for the openUrl handlers to be in
>>> the platform handlers? We have XDG-code in QtCore already (mime types),
>>> so we should have all the information in Core already to implement the
>>> functionality, should we not?
>>> 
>>> 
>>> I believe the reason for this is mainly history. Moving this to Qt Core 
>>> makes sense IMO.
>>> 
>>> I don’t think you need a separate plugin for Qt Core to implement this 
>>> though. I’m a bit unsure about the windows code, but on Linux and macOS 
>>> it’s simply launching ‘xdg-open’ or ‘open’. It would probably fit better to 
>>> simply follow the usual pattern for Qt Core with a _platform.cpp 
>>> implementation file.
>>> 
>>> Cheers,
>>> Lars
>>> 
>>> 
>>> 
>>> Thanks,
>>> Marc
>>> 
>>> --
>>> Marc Mutz  (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
>>> 
>>> 
>>> --
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>> 
>>> 
>>> --
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

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

> The concrete need for QtNetworkAuth at the moment is
> QDesktopServices::setUrlHandler() and
> QDesktopServices::unsetUrlHandler().
> There is a new (Qt 6.8) class which needs to use these *) and that
> would create a module-level Gui dependency (unless using plugins or
> somesuch).
>
> Hence I'm wondering if, as a pragmatic pre-move, moving the
> implementation of those two functions behind a private header in
> QtCore (IIUC this is Tor Arne's proposal) would be
> sensible/acceptable?
>
> *) In order to be able to use custom-scheme and https-scheme redirect_uris
>
> Cheers,
> Juha
>
> > On 6 May 2024, at 09:51, Lars Knoll via Development 
> >  wrote:
> >
> >
> >
> > On 6 May 2024, at 09:02, Marc Mutz via Development 
> >  wrote:
> >
> > Hi,
> >
> > Juha is currently improving the OAuth implementation in QtNetworkAuth.
> > The protocol involves launching the system browser to get an access
> > code, in turn used to get access tokens with which services can then be
> > accessed.
> >
> > OAuth therefore requires a UI to run the browser in, but not necessarily
> > a _G_UI (the system browser could be lynx). Even if a CLI tool like a
> > mail fetcher, backup program, or VPN client will eventually launch
> > Firefox or Chrome, I think it's too much to ask to link to QtGui just to
> > do the equivalent of exec xdf-open .
> >
> >
> > I’d agree with that. And there’s no way to do OAuth without launching a 
> > browser during the authentication process.
> >
> >
> > I've looked at the implementation of openUrl(), and the only
> > Gui-dependency is on the platform helpers. The handler registration is
> > only using Core functionality.
> >
> > I would therefore propose to move the services code from Gui to Core
> > (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
> > dependency.
> >
> > After a quick look, I can see two ways to do that:
> > - keep the platform handling code in the platform helpers, incl. Gui
> > dependency, and only move the handler registration to Core
> > - move the platform url handlers out of the platform helpers into (a
> > plugin for) Core
> >
> > The first would enable users to write their own handlers w/o Gui
> > dependency, but has the disadvantage that the code behaves differently,
> > depending on whether QtGui is loaded or not.
> >
> > The second would be more work, but with consistently better user experience.
> >
> > Is there a reason other than history for the openUrl handlers to be in
> > the platform handlers? We have XDG-code in QtCore already (mime types),
> > so we should have all the information in Core already to implement the
> > functionality, should we not?
> >
> >
> > I believe the reason for this is mainly history. Moving this to Qt Core 
> > makes sense IMO.
> >
> > I don’t think you need a separate plugin for Qt Core to implement this 
> > though. I’m a bit unsure about the windows code, but on Linux and macOS 
> > it’s simply launching ‘xdg-open’ or ‘open’. It would probably fit better to 
> > simply follow the usual pattern for Qt Core with a _platform.cpp 
> > implementation file.
> >
> > Cheers,
> > Lars
> >
> >
> >
> > Thanks,
> > Marc
> >
> > --
> > Marc Mutz  (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
> >
> >
> > --
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
> >
> > --
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø via Development]

> On 6 May 2024, at 12:31, Allan Sandfeld Jensen  wrote:
> 
> On Monday 6 May 2024 10:02:43 CEST Tor Arne Vestbø via Development wrote:
>> There’s some overlap here with the more modern features of intents,
>> activities, etc, which we are hoping to add proper APIs for at some point,
>> so I suggest not doing any public API changes as part of this.
> 
>> We can move the registration APIs to QtCore as private APIs, that
>> QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move
>> the URL handling part of the QPA plugins to QtCore under
>> src/corelib/platform
> 
> Is there any problem in moving the class all the way if we preserve the 
> headers under both QtGui and QtCore? Since QtCore is always linked when QtGui 
> is linked, it shouldn't affect BC should it? The main problem with moving 
> classes between Qt modules is source compatibility, or I am forgetting 
> something?

As I mentioned, there is overlap with similar features that we want to spend 
more time on researching. Let’s not couple the needs of QtNetworkAuth to that 
work, and let’s not rush QDesktopServices wholesale into QtCore either.

Cheers,
Tor Arne

> 
> Allan
> 
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Allan Sandfeld Jensen]

On Monday 6 May 2024 10:02:43 CEST Tor Arne Vestbø via Development wrote:
> There’s some overlap here with the more modern features of intents,
> activities, etc, which we are hoping to add proper APIs for at some point,
> so I suggest not doing any public API changes as part of this.
 
> We can move the registration APIs to QtCore as private APIs, that
> QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move
> the URL handling part of the QPA plugins to QtCore under
> src/corelib/platform
 
Is there any problem in moving the class all the way if we preserve the 
headers under both QtGui and QtCore? Since QtCore is always linked when QtGui 
is linked, it shouldn't affect BC should it? The main problem with moving 
classes between Qt modules is source compatibility, or I am forgetting 
something?

Allan


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Juha Vuolle]

ma 6. toukok. 2024 klo 11.05 Tor Arne Vestbø via Development
(development@qt-project.org) kirjoitti:
>
> There’s some overlap here with the more modern features of intents, 
> activities, etc, which we are hoping to add proper APIs for at some point, so 
> I suggest not doing any public API changes as part of this.
>
> We can move the registration APIs to QtCore as private APIs, that 
> QtNetworkAuth can use, and QDesktopServices can plumb to. And we can move the 
> URL handling part of the QPA plugins to QtCore under src/corelib/platform

Imho (eventually) moving the public header to QtCore would make sense,
but as I understand it, there's some concerns and issues too.

QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
at the user's discretion, and thus that currently won't force a Gui
dependency.
The concrete need for QtNetworkAuth at the moment is
QDesktopServices::setUrlHandler() and
QDesktopServices::unsetUrlHandler().
There is a new (Qt 6.8) class which needs to use these *) and that
would create a module-level Gui dependency (unless using plugins or
somesuch).

Hence I'm wondering if, as a pragmatic pre-move, moving the
implementation of those two functions behind a private header in
QtCore (IIUC this is Tor Arne's proposal) would be
sensible/acceptable?

*) In order to be able to use custom-scheme and https-scheme redirect_uris

Cheers,
Juha

> On 6 May 2024, at 09:51, Lars Knoll via Development 
>  wrote:
>
>
>
> On 6 May 2024, at 09:02, Marc Mutz via Development 
>  wrote:
>
> Hi,
>
> Juha is currently improving the OAuth implementation in QtNetworkAuth.
> The protocol involves launching the system browser to get an access
> code, in turn used to get access tokens with which services can then be
> accessed.
>
> OAuth therefore requires a UI to run the browser in, but not necessarily
> a _G_UI (the system browser could be lynx). Even if a CLI tool like a
> mail fetcher, backup program, or VPN client will eventually launch
> Firefox or Chrome, I think it's too much to ask to link to QtGui just to
> do the equivalent of exec xdf-open .
>
>
> I’d agree with that. And there’s no way to do OAuth without launching a 
> browser during the authentication process.
>
>
> I've looked at the implementation of openUrl(), and the only
> Gui-dependency is on the platform helpers. The handler registration is
> only using Core functionality.
>
> I would therefore propose to move the services code from Gui to Core
> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
> dependency.
>
> After a quick look, I can see two ways to do that:
> - keep the platform handling code in the platform helpers, incl. Gui
> dependency, and only move the handler registration to Core
> - move the platform url handlers out of the platform helpers into (a
> plugin for) Core
>
> The first would enable users to write their own handlers w/o Gui
> dependency, but has the disadvantage that the code behaves differently,
> depending on whether QtGui is loaded or not.
>
> The second would be more work, but with consistently better user experience.
>
> Is there a reason other than history for the openUrl handlers to be in
> the platform handlers? We have XDG-code in QtCore already (mime types),
> so we should have all the information in Core already to implement the
> functionality, should we not?
>
>
> I believe the reason for this is mainly history. Moving this to Qt Core makes 
> sense IMO.
>
> I don’t think you need a separate plugin for Qt Core to implement this 
> though. I’m a bit unsure about the windows code, but on Linux and macOS it’s 
> simply launching ‘xdg-open’ or ‘open’. It would probably fit better to simply 
> follow the usual pattern for Qt Core with a _platform.cpp implementation file.
>
> Cheers,
> Lars
>
>
>
> Thanks,
> Marc
>
> --
> Marc Mutz  (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
>
>
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
>
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Tor Arne Vestbø via Development]

There’s some overlap here with the more modern features of intents, activities, 
etc, which we are hoping to add proper APIs for at some point, so I suggest not 
doing any public API changes as part of this.

We can move the registration APIs to QtCore as private APIs, that QtNetworkAuth 
can use, and QDesktopServices can plumb to. And we can move the URL handling 
part of the QPA plugins to QtCore under src/corelib/platform

Cheers,
Tor Arne

On 6 May 2024, at 09:51, Lars Knoll via Development 
 wrote:



On 6 May 2024, at 09:02, Marc Mutz via Development  
wrote:

Hi,

Juha is currently improving the OAuth implementation in QtNetworkAuth.
The protocol involves launching the system browser to get an access
code, in turn used to get access tokens with which services can then be
accessed.

OAuth therefore requires a UI to run the browser in, but not necessarily
a _G_UI (the system browser could be lynx). Even if a CLI tool like a
mail fetcher, backup program, or VPN client will eventually launch
Firefox or Chrome, I think it's too much to ask to link to QtGui just to
do the equivalent of exec xdf-open .

I’d agree with that. And there’s no way to do OAuth without launching a browser 
during the authentication process.

I've looked at the implementation of openUrl(), and the only
Gui-dependency is on the platform helpers. The handler registration is
only using Core functionality.

I would therefore propose to move the services code from Gui to Core
(QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
dependency.

After a quick look, I can see two ways to do that:
- keep the platform handling code in the platform helpers, incl. Gui
dependency, and only move the handler registration to Core
- move the platform url handlers out of the platform helpers into (a
plugin for) Core

The first would enable users to write their own handlers w/o Gui
dependency, but has the disadvantage that the code behaves differently,
depending on whether QtGui is loaded or not.

The second would be more work, but with consistently better user experience.

Is there a reason other than history for the openUrl handlers to be in
the platform handlers? We have XDG-code in QtCore already (mime types),
so we should have all the information in Core already to implement the
functionality, should we not?

I believe the reason for this is mainly history. Moving this to Qt Core makes 
sense IMO.

I don’t think you need a separate plugin for Qt Core to implement this though. 
I’m a bit unsure about the windows code, but on Linux and macOS it’s simply 
launching ‘xdg-open’ or ‘open’. It would probably fit better to simply follow 
the usual pattern for Qt Core with a _platform.cpp implementation file.

Cheers,
Lars



Thanks,
Marc

--
Marc Mutz  (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

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Ilya Fedin]

On Mon, 6 May 2024 09:51:56 +0200
Lars Knoll via Development  wrote:

> I’m a bit unsure about the windows code, but on Linux
> and macOS it’s simply launching ‘xdg-open’ or ‘open’.

That's not really the truth for Linux: it also does D-Bus calls to
xdg-desktop-portal. While this isn't really a GUI thing by its own, I
imagine calling QtDBus from QtCore is going to be a problem. There's
also portalWindowIdentifier virtual which gets overloaded by xcb and
wayland QPAs so in case xdg-desktop-portal wants to present a dialog
regarding opening the URL, it gets parent window from Qt which allows
the dialog to be modal.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Lars Knoll via Development]

> On 6 May 2024, at 09:02, Marc Mutz via Development 
>  wrote:
> 
> Hi,
> 
> Juha is currently improving the OAuth implementation in QtNetworkAuth. 
> The protocol involves launching the system browser to get an access 
> code, in turn used to get access tokens with which services can then be 
> accessed.
> 
> OAuth therefore requires a UI to run the browser in, but not necessarily 
> a _G_UI (the system browser could be lynx). Even if a CLI tool like a 
> mail fetcher, backup program, or VPN client will eventually launch 
> Firefox or Chrome, I think it's too much to ask to link to QtGui just to 
> do the equivalent of exec xdf-open .

I’d agree with that. And there’s no way to do OAuth without launching a browser 
during the authentication process.
> 
> I've looked at the implementation of openUrl(), and the only 
> Gui-dependency is on the platform helpers. The handler registration is 
> only using Core functionality.
> 
> I would therefore propose to move the services code from Gui to Core 
> (QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui 
> dependency.
> 
> After a quick look, I can see two ways to do that:
> - keep the platform handling code in the platform helpers, incl. Gui 
> dependency, and only move the handler registration to Core
> - move the platform url handlers out of the platform helpers into (a 
> plugin for) Core
> 
> The first would enable users to write their own handlers w/o Gui 
> dependency, but has the disadvantage that the code behaves differently, 
> depending on whether QtGui is loaded or not.
> 
> The second would be more work, but with consistently better user experience.
> 
> Is there a reason other than history for the openUrl handlers to be in 
> the platform handlers? We have XDG-code in QtCore already (mime types), 
> so we should have all the information in Core already to implement the 
> functionality, should we not?

I believe the reason for this is mainly history. Moving this to Qt Core makes 
sense IMO.

I don’t think you need a separate plugin for Qt Core to implement this though. 
I’m a bit unsure about the windows code, but on Linux and macOS it’s simply 
launching ‘xdg-open’ or ‘open’. It would probably fit better to simply follow 
the usual pattern for Qt Core with a _platform.cpp implementation file.

Cheers,
Lars


> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz  (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

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Moving QDesktopServices from Gui to Core?

[Jaroslaw Kobus via Development]

The basic question: does it mean moving any public class / function from one 
lib into another? If so, how do you want to resolve the BC issue, especially on 
Win?

Jarek


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Monday, May 6, 2024 9:02 AM
To: development@qt-project.org
Subject: [Development] Moving QDesktopServices from Gui to Core?

Hi,

Juha is currently improving the OAuth implementation in QtNetworkAuth.
The protocol involves launching the system browser to get an access
code, in turn used to get access tokens with which services can then be
accessed.

OAuth therefore requires a UI to run the browser in, but not necessarily
a _G_UI (the system browser could be lynx). Even if a CLI tool like a
mail fetcher, backup program, or VPN client will eventually launch
Firefox or Chrome, I think it's too much to ask to link to QtGui just to
do the equivalent of exec xdf-open .

I've looked at the implementation of openUrl(), and the only
Gui-dependency is on the platform helpers. The handler registration is
only using Core functionality.

I would therefore propose to move the services code from Gui to Core
(QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui
dependency.

After a quick look, I can see two ways to do that:
- keep the platform handling code in the platform helpers, incl. Gui
dependency, and only move the handler registration to Core
- move the platform url handlers out of the platform helpers into (a
plugin for) Core

The first would enable users to write their own handlers w/o Gui
dependency, but has the disadvantage that the code behaves differently,
depending on whether QtGui is loaded or not.

The second would be more work, but with consistently better user experience.

Is there a reason other than history for the openUrl handlers to be in
the platform handlers? We have XDG-code in QtCore already (mime types),
so we should have all the information in Core already to implement the
functionality, should we not?

Thanks,
Marc

--
Marc Mutz  (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
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Moving QDesktopServices from Gui to Core?

[Marc Mutz via Development]

Hi,

Juha is currently improving the OAuth implementation in QtNetworkAuth. 
The protocol involves launching the system browser to get an access 
code, in turn used to get access tokens with which services can then be 
accessed.

OAuth therefore requires a UI to run the browser in, but not necessarily 
a _G_UI (the system browser could be lynx). Even if a CLI tool like a 
mail fetcher, backup program, or VPN client will eventually launch 
Firefox or Chrome, I think it's too much to ask to link to QtGui just to 
do the equivalent of exec xdf-open .

I've looked at the implementation of openUrl(), and the only 
Gui-dependency is on the platform helpers. The handler registration is 
only using Core functionality.

I would therefore propose to move the services code from Gui to Core 
(QTBUG-125085), so QtNetworkAuth can access it w/o incurring a Gui 
dependency.

After a quick look, I can see two ways to do that:
- keep the platform handling code in the platform helpers, incl. Gui 
dependency, and only move the handler registration to Core
- move the platform url handlers out of the platform helpers into (a 
plugin for) Core

The first would enable users to write their own handlers w/o Gui 
dependency, but has the disadvantage that the code behaves differently, 
depending on whether QtGui is loaded or not.

The second would be more work, but with consistently better user experience.

Is there a reason other than history for the openUrl handlers to be in 
the platform handlers? We have XDG-code in QtCore already (mime types), 
so we should have all the information in Core already to implement the 
functionality, should we not?

Thanks,
Marc

-- 
Marc Mutz  (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