[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240507/e16ae035/attachment.bin>