On 2022 Sep 16, at 11:13, JiDe Zhang <zc...@live.com<mailto:zc...@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-boun...@qt-project.org<mailto:development-boun...@qt-project.org>> on behalf of Ilya Fedin <fedin-ilja2...@ya.ru<mailto:fedin-ilja2...@ya.ru>> Sent: Friday, September 16, 2022 14:56 To: development@qt-project.org<mailto:development@qt-project.org> <development@qt-project.org<mailto:development@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.rutle...@qt.io<mailto:shawn.rutle...@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@qt-project.org<mailto:Development@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@qt-project.org<mailto: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
