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 <marc.m...@qt.io> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
