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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
