[Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 16/09/2022 07:32, Lars Knoll wrote:
> 
> But the native print dialogs do currently all live inside Qt print support, so I don’t see why we shouldn’t add one more.

Lars, note that we do not create a new print dialog here. We do not do 
any GUI design or change as part of our project. We only add a new 
method to obtain the available printers, their capabilities and options, 
and to send off print jobs to them.

Common Print Dialog Backends (CPDB, 
https://openprinting.github.io/achievements/#common-print-dialog-backends), 
not to be confused with the earlier Common Print Dialog (CPD, 
https://openprinting.github.io/achievements/#common-print-dialog) 
approach, is about having **GUI-toolkit-independent**, D-Bus-coupled 
backends to communicate with the different print technologies (CUPS, 
print-to-file, cloud printing services, ...), so that the responsibility 
about this communication moves from the GUI toolkit developers (or app 
developers) to the developers of the print technologies (OpenPrinting, 
cloud service providers, ...).

We want to make a CPDB frontend out of the Qt print dialog (we have 
already done so with the GTK print dialog). For this we have principally 
two ways to do it:

First is to create a new Qt print backend, what, instead of 
communicating directly with CUPS, communicates with the CPDB backends. 
It is some kind of "middle end", on one end being a Qt print backend and 
on the other end being a CPDB frontend.

The second is to throw the backend concept of the Qt dialog over board 
and replace it by CPDB, the Qt print dialog itself using cpdb-libs to 
connect to backends, which are now only the CPDB backends, no Qt print 
backends any more. By conditional compiling one could decide here at 
build time to use the CPDB concept, the old Qt print backend concept, or 
both (and in that case which has priority).

The first solution gives full flexibility at run time, especially if in 
a distro the cpdb-libs are available but not installed by default. 
Distros not providing cpdb-libs are also not a problem here, as there is 
no hard dependency on them for the Qt print dialog itself.

The second solution has the advantage of a deeper integration of the 
CPDB concept in the Qt print dialog as Qt's own print dialog backend 
interface could not get a bottle neck. But we get a hard dependency on 
cpdb-libs already at build time.

I will release cpdb-libs 2.0 ASAP, meaning when Gaurav has both dialogs 
working well enough and so I know about the completeness of the API.

Then distros will adopt the CPDB concept as we have all components 
available: GTK and Qt print dialogs, cpdb-libs, and CUPS and 
print-to-file CPDB backends, the CUPS backend following the PPD-less 
all-IPP architecture, allowing a smooth transition into CUPS 3.x.

>>
>>> 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.
> 
> I am unsure whether we can get rid of CUPS and replace it with CPD, or whether we will need both side by side (and select the supported one at runtime). What’s the status here, are all Linux distributions nowadays supporting CPD? If yes, then we can either remove CUPS, or at least turn it into a compile time configuration option.

The distros do not use CPDB by default currently as current print 
dialogs do not use CPDB. Libraries and backends are available in some 
distro's optional package repositories, like for example in Ubuntu's 
Universe.

The switchover to CPDB is our way to get into the New Architecture, 
PPD-less, all-IPP printing. The CUPS CPDB backend is already made for 
this and if print dialogs adopt CPDB they are working correctly with the 
New Architecture. The current CUPS also works with all-IPP clients 
without PPD support. So once CPDB-enabled print dialogs are in place the 
transition from CUPS 2.x to CUPS 3.x will be completely transparent for 
users.

The easiest transition for the Qt dialog from using its own CUPS backend 
to using CPDB (built-in or as backend) is to have Qt at least 
temporarily support both, also supporting both makes it easier for 
ditribution of distro-independent binary packages, like commercial Qt 
applications, so that they fit into both classic and CPDB system 
environments.

If the Qt in use by an app supports both and also the system supports 
both (CUPS is installed, the cUPS CPDB backend is installed, CPDB should 
get prioritized.

    Till