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 <development-boun...@qt-project.org> on behalf of Marc Mutz via Development <development@qt-project.org> 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 <url>. 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 <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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
