[Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 16, at 11:13, JiDe Zhang <zccrs at live.com<mailto:zccrs at live.com>> wrote:

Whether or not CPD should be implementation in Qt, we can first add some QPA abstraction for Print Dialog like as File Dialog. If the implementation of XDG portal in desktop environment is supported CPD, and Qt supported org.freedesktop.portal.Print, then we can use CPD in Qt applications.

Yes, and if that and org.freedesktop.portal.Print<https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Print> are both available (which we could check by introspecting d-bus, although I’m not sure if that’s the first choice), I guess the maximum number of choices would be between a dialog helper for the portal dialog, another one for GTK, QPrintDialog (the actual widget implementation), and a QML implementation?

QFileDialog::DontUseNativeDialog is an option, and the docs explain "By default, the native file dialog is used unless you use a subclass of QFileDialog that contains the Q_OBJECT macro, or the platform does not have a native dialog of the type that you require.”  (Scribus is an example of an application that adds features to their version of QFileDialog, so they really want to use that one, not the native one.  https://github.com/scribusproject/scribus/blob/6078676dff094fa9f0ffedf2170a6c7b5112de23/scribus/ui/scfilewidget.h)  So I guess we should follow the same pattern in QPrintDialog?  It has options, but not that one.  If the option exists but is not set, it would be ok for QPrintDialog to use the native dialog by default, if possible.  (And we don’t encourage anyone to instantiate a dialog and then modify it programmatically, that’s not really the purpose of that flag.)  So widget apps don’t need to change anything, just keep using QPrintDialog.

A few years ago I did some refactoring in QFileDialog, because early in Qt 5 it was still instantiating all the widgets that make up the dialog, even if you ended up showing the native one instead.  (Some of those widgets needed to exist because they were holding state.  That was weird.)  So let’s not repeat that mistake either.  ;-)  https://codereview.qt-project.org/c/qt/qtbase/+/67510

So yeah, these could take pressure off from needing to change qprintdialog_unix.cpp to actually populate itself a different way, but maybe it should still be done eventually.

________________________________
From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> on behalf of Ilya Fedin <fedin-ilja2010 at ya.ru<mailto:fedin-ilja2010 at ya.ru>>
Sent: Friday, September 16, 2022 14:56
To: development at qt-project.org<mailto:development at qt-project.org> <development at qt-project.org<mailto:development at qt-project.org>>
Subject: Re: [Development] Adding CPD support to Qt print dialog

On Fri, 16 Sep 2022 06:32:38 +0000
Shawn Rutledge <Shawn.Rutledge at qt.io<mailto:Shawn.Rutledge at qt.io>> wrote:

> Another aspect that I haven’t kept up with very well is how
> containerized applications should do printing.  We have “portal”
> support for file dialogs, for example, but is CPDB intended to work
> the same way regardless whether the app has such security
> restrictions or not?  For that matter, as a design principle, is
> everyone still sure that the way for an application to reach outside
> its container is D-Bus interfaces that are designed to be trusted?
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.gnome.org%2Fmclasen%2F2018%2F07%2F19%2Fflatpak-a-look-behind-the-portal%2F&data=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Bv3C78qNStklLcgcdZQ5UGMG3wJHRYKLxJ9xJ13cmmo%3D&reserved=0

There's Print portal for that purpose:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflatpak.github.io%2Fxdg-desktop-portal%2F%23gdbus-org.freedesktop.portal.Print&data=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hcj6nnNUiO0Nlg17slHmpO4FcD0CWB%2FMUJR1%2BNlx5qk%3D&reserved=0

What good about it is it shows native file dialogs provided by the
environment that comes as a portal backend daemon. Just like the
FileDialog portal, it doesn't matter for the portal whether the
application is actually sandboxed, so it could be used even in
non-sandboxed environment.
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopment&data=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s3IG2h%2FEVUDio0QFANi3TDd1UGj5QJce3hXWRiWSVPI%3D&reserved=0
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220916/6a15d7fb/attachment-0001.htm>