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