Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 16, at 11:13, JiDe Zhang 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
 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 
mailto:development-boun...@qt-project.org>> 
on behalf of Ilya Fedin mailto:fedin-ilja2...@ya.ru>>
Sent: Friday, September 16, 2022 14:56
To: 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 +
Shawn Rutledge 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%2Fdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Bv3C78qNStklLcgcdZQ5UGMG3wJHRYKLxJ9xJ13cmmo%3Dreserved=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.Printdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hcj6nnNUiO0Nlg17slHmpO4FcD0CWB%2FMUJR1%2BNlx5qk%3Dreserved=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
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopmentdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=s3IG2h%2FEVUDio0QFANi3TDd1UGj5QJce3hXWRiWSVPI%3Dreserved=0

Re: [Development] Adding CPD support to Qt print dialog

[JiDe Zhang]

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.


From: Development  on behalf of Ilya Fedin 

Sent: Friday, September 16, 2022 14:56
To: development@qt-project.org 
Subject: Re: [Development] Adding CPD support to Qt print dialog

On Fri, 16 Sep 2022 06:32:38 +
Shawn Rutledge  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%2Fdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Bv3C78qNStklLcgcdZQ5UGMG3wJHRYKLxJ9xJ13cmmo%3Dreserved=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.Printdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hcj6nnNUiO0Nlg17slHmpO4FcD0CWB%2FMUJR1%2BNlx5qk%3Dreserved=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
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopmentdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=s3IG2h%2FEVUDio0QFANi3TDd1UGj5QJce3hXWRiWSVPI%3Dreserved=0
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 6.4.0 RC released

[Jani Heikkinen]

Hi all!

We have released the Qt 6.4.0 RC.  As earlier you can get it via online 
installer. Src packages are also available in the Qt Account and 
download.qt.io. Delta to the beta4 attached. Please make sure you report all 
findings in Jira. 

The target is to release Qt 6.4.0 in two weeks so please inform me immediately 
if you find something new which should be fixed before the release. 

br,
Jani Heikkinen
Release Manager
qt5.git
2fc16d16735314fe3d4e494d68693ec3dfe1fa9f Adjust submodule branches
0adae901eea94515e072b6834363a8111c6b4c81 Coin: Add Android OpenSSL scripts to 
macOS 12 provisioning target
qt3d:
qt5compat:
qtactiveqt:
qtbase:
b4586e0c050653359d992d14f9b7a3c9f546c0a1 Do not make extra copy of public 
headers for external headers module
3a7646f02a5a1b6220a675128c52a675cc856977 QNetworkReply: Fix missing final 
emission of readyRead
1f6213713d8e51b8d236c6be41c92b36fe95e3c1 wasm: add Window.localStorage settings 
backend
ffa3c3579acaf3291b0cfa7e5670313d576d5d49 Propagate the copy event correctly to 
Qt widgets on WASM
9fe9c41f8377d4194108c69b3fc684532c630e9c Avoid crash in 
QTextMarkdownWriter::writeBlock()
185fdcad18f3b3e42cb02f5cf3f1925ec926d191 JUnit: Don't turn seconds into 
kilo-seconds
0442e81cbbaa2e64ee42ec98edb9551017db78d0 uic: Add QPdfView
5543e2dece80f08365e74b130bf8af09944f0854 Work round macOS's omission of en_DE 
from its own uiLanguages()
dc7e6d14d876cd3ed076b7a7bb542b9be3cbbfee Use QVarLengthFlatMap for 
QPointingDevicePrivate::activePoints
f19f512d5e8f12f15fea6f216762af0bba1b4e4b Clear the timer target time when 
stopping a timer on WASM
17df321f1db187505e1204af6157742e4a633010 QTextStream: Fix logical error in 
setEncoding
2b2c6a717c6680473edaebd8c1699933412ef842 Refix QDockwidget drag out dockwidget
b0cadd5ed275dd64c19c15c0a09fe5d2383badf1 Fix crash when setting override cursor 
on multiple clients
4d10022a8d9b0867e8f6230beb9b1794ae11a5c3 Reland macdeployqt: Don't copy .prl 
files into the Resources folder
3602a95a8c5b134561651e632c4c121b35850303 Correct typo in destination path 
variable names
85d28ea39146ffd1bd904e551f4630f86812f702 tst_QSslSocket::oldErrorsOnSocketReuse 
- make it work with OpenSSL v3
6806192e87bed03d7c9d96168509ae2cd3a10629 Fix warning from testing assignment
5b2924b4b0ff0df70f3937bbfe310e90e6788242 Update zconf.h prefixes to match zlib 
v1.2.12 update
bf958e22ce9a6d537eb48bdd55b5e7ac62bfe529 tst_QSslSocket: regenerate certificate 
used for setLocalCertificateChain
8edb27d7df69e643667e2fb301702a65c1364473 Windows: avoid losing transparency 
when pasting images into Qt apps
134abb7eef2683b13b8d8c0be029795791e0233e Doc: 3rd party: Fix reference to 
FreeType LICENSE.txt
11ac2ccaef36e548844c228d8e929a6304feae31 tst_QSslSocket::protocolServerSide - 
make it work with OpenSSL v3
70ae87a51c01ee900bd554780186459515c9ed05 Use testlib for 
multiPointRawEventTranslationOnTouchScreen events
bff012b53f52ec31740e14b70af3755390cb218a Windows QPA: send UIA focus 
notification after window activation
c7ce952d6fcc033bd344acaa4caa95ee958687c9 CMake: Add reference documentation for 
QT_IOS_LAUNCH_SCREEN
37d673313d65852c8c37b8066158046df9b5f49a Android A11Y: Check for active surface 
before calling into native code
d076c31bfafcf81dbd44b118a28e4e1e3d004ab5 QVariant: fix conversions of Q_ENUM 
that are QFlags<> to string
192df6ef4772535b110957eb684da72237f9a510 Add CBOR documentation
255234136c678f26b348f0c9cfeaebd9e20d5411 QGtk3Dialog: remove the #include for 
empty moc
6f482054d74423501420d94cb40edb6bd1a19dc9 xcb: set _NET_STARTUP_ID at client 
leader window
22dc3ee80188b61a9aceef27ac61a736e41ba858 xcb: fix D in same xembed client
8ba68e36b846cabc0b9379f2a0719fb82f7f07a0 xcb: use global coordinates for 
position of D for xembed client
2932130a8ee0157d3158a380924b7e9df8b52a2d QVariant: fix conversions of string 
keys to Q_ENUM that are QFlags<>
abaf1aa13444df9930173451585d6be6b8c0d8c4 Doc: Update QMetaType::metaObject() 
descriptions
cb61bea5913e75edd94d73f527ceb88769e8556f tst_QSslKey - make OpenSSL v3 
detection fully runtime
88d06dd980814801e0851f4cb125dd6199b5da08 Fix two trivial defects in testlib docs
863e308e6b49e3ea263c518cd9491daabb41e1d4 Provide CMake guidance for skipping 
whole tests
9516fe526ef7a57a9507feb84f20a6dd53e0b279 macdeployqt: Fix deploying libraries 
with `reexport`
6cdc2fc0f4bc944bda6a9d0abfa0512672cda43a QLocale: port to qsizetype [2/N]: 
remainder (qlocale_win.cpp partial)
e8e91ef35ce559b31e63cbd1c2a87ea111fbed58 [docs] Fix ints that should be 
qsizetype [src/corelib/text]
53997b5196f1beb3d777a16e7c12a8bbb6688fa8 widgets: avoid setting 
X11BypassWindowManagerHint in QToolBar
c51eb3dfc3de9287260639b0e8b7d419e023b03c Blacklist: 
tst_QGraphicsAnchorLayout::layoutDirection for Ubuntu 22.04
3bf1786d02cc4e44872a6a339edc2cb589322c1e Android A11Y: Notify android about 
scroll events
04147c45856c07a26eb39c2af6d7885a7f54e976 Doc: fix example repo URL
78a0203ffaa4b0061e0d890ee7e67ae69e202733 wasm: add Emscripten version check for 
apps

Re: [Development] Adding CPD support to Qt print dialog

[Ilya Fedin]

On Fri, 16 Sep 2022 06:32:38 +
Shawn Rutledge  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://blogs.gnome.org/mclasen/2018/07/19/flatpak-a-look-behind-the-portal/

There's Print portal for that purpose:
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Print

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
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 16, at 00:20, Gaurav Guleria 
mailto:gaurav.g...@gmail.com>> wrote:

Hello all,

I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add and 
improve Common Print Dialog (CPD) support to existing print dialogs like GTK 
and Qt. More about CPD can be read here: 
https://openprinting.github.io/projects/04-print-dialog/.

I wanted to ask about your opinions on the implementation and the way we should 
proceed with it. I talked with a few people and read this old article here: 
https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt team prefers CPD support 
as a plugin rather than a direct integration into the QPrintDialog.

Just to summarize briefly, implementing CPD support directly in the print 
dialog would mean that the Qt team wouldn't have to worry about any future CUPS 
changes, or any other print backends for that matter, as CPD will handle them 
all instead.

It would be really helpful if you could share your views on this and give your 
suggestions.

And Chris refers us to an email from Lars in 2020:

On 2020 May 20, at 09:12, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

Hi Priydarshi!

Sorry for the delayed answer.

Great to hear that you want to work on printing for Qt. All our code is in 
qtbase/src/printsupport, where we have cross-platform printing for Windows, 
macOS and CUPS. For Windows and macOS we use the native dialogs, for CUPS, we 
have our own set.

The easiest and best solution would probably be to integrate there, and have a 
configure time check for the CPDB libs, and in that case compile in code that 
uses the CPDB dialogs instead of our own implementations.

Doing the changes inside qtprintsupport (as opposed to a new Add-on) has the 
advantage that existing applications would automatically benefit from the new 
functionality.

Along with Chris, I’m wondering why you think it should be a plugin.

Anyway it seems some misunderstandings are possible.  Lars wrote "code that 
uses the CPDB dialogs instead of our own implementations”… but are there 
replacement GUI dialogs? The web site says it’s about "separating the print 
dialogs of different GUI toolkits and applications (GTK, Qt, LibreOffice, …) 
from the different print technologies (CUPS/IPP, Google Cloud Print, …) so that 
they can get developed independently”.  And they use D-Bus.  Here are the 
current D-Bus specifications (which have been modified recently): 
https://github.com/OpenPrinting/cpdb-libs/tree/master/cpdb/interface So now it 
seems we bump into the typical GTK/glib pattern that they like to provide a 
stable C interface, as a higher priority than a stable D-Bus interface.  But Qt 
has its own D-Bus implementation, so we tend to prefer using that, rather than 
using some external library that uses some other library that talks to D-Bus.  
But if you really want to use the library, maybe that could be a reason to do 
dynamic loading?

On most Linux distros, Qt gets installed as normal packages, so it’s up to the 
packagers to ensure that Qt’s dependencies shall be installed as 
pre-requisites.  In that case, if it ends up that cpdb-lib is a dependency, and 
it gets installed automatically, that’s fine.  But commercial applications, and 
applications on other operating systems, tend to get developed with a version 
of Qt that comes from the Qt installer, so then dependency management is 
trickier, and we sometimes use dynamic loading of “iffy” libraries that may or 
may not already be installed.  (But if CPDB really becomes universal, then 
maybe within a few years we could assume that it’s always installed.)

If you’d develop with Qt D-Bus https://doc.qt.io/qt-6/qtdbus-index.html you 
would not have a library dependency problem; but instead, you’d have the 
problem that the D-Bus interface for this service may change, that requires 
maintenance, and someone has to follow along with the changes that are being 
done in cpdb-lib, so that our implementation keeps working like theirs does.  
But so far, we are getting away with this approach in other cases, such as the 
AppMenu and StatusNotifier interfaces.  So I think I’d still try to do it that 
way; I just hope they don't break compatibility often.  GTK/glib people may say 
they want to be able to break compatibility at any time, but to me it doesn’t 
make sense to say that an interface specification is more fluid than a C 
interface that implements it.  The XML has to be published and versioned.  When 
it’s stable, both the C and D-Bus interfaces stop changing.  And if the world 
treats the D-Bus interface as being stable, they may feel some drag, and be 
reluctant to break compatibility; IMO that’s as it should be.

So my assumption is you don’t necessarily have to modify the design of 
QPrintDialog much, or replace it with another dialog, but rather that there 
will be a new way of populating the printers there, getting their capabilities, 
starting print jobs and so on; is that right?  If that's not true, and actually 
you need a