[Development] Moving QDesktopServices from Gui to Core?
Lars Knoll
lars at knoll.priv.no
Mon May 6 09:51:56 CEST 2024
> On 6 May 2024, at 09:02, Marc Mutz via Development <development at qt-project.org> 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 <url>.
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 <marc.mutz at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
More information about the Development
mailing list