On 01/06/2023 00:18, Thorsten Alteholz wrote:
Hi Till,
On Wed, 31 May 2023, Till Kamppeter wrote:
I do not know how far the Bookworm release process has progressed and
whether the new development cycle has already started.
the release is planned on 2023-06-10 and afterwards the fun may begin
again.
OK, so the week after the next one, Debian can start to get the nice new
printing features ...
For the New Architecture for printing Debian needs to have the
following packages:
(...)
I am missing KDE/QT in this list. Is everything already available there?
Would KDE users still be able to print? In your PPA you only mention
gtk4.
I have also Qt6 there with a print dialog which correctly works with
CPDB. See also my instructions:
https://openprinting.github.io/OpenPrinting-News-May-2023/#test-the-gui-changes-for-the-new-architecture
As the print dialog did not get actually changed for ~20 years,
backporting the CPDB support to older versions of Qt should not be that
complicated.
I think xfce, lxde, cinnamon and some other desktop environments
still depend on gtk3. Are there any efforts to implement CPDB there as
well?
I did not plan any backports yet, was primarily happy that CPDB support
made it into the current GTK.
Also in GTK the print dialog stayed unchanged for long time, so that
here a backport should also not be too complicated.
It looks like the old printing architecture needs to be available in
parallel to CPDB. Would that be possible? If I remember correctly there
are some hurdles, aren't they? What can we do when cups3 appears?
Principally this is no problem at all. Some print dialogs using CPDB and
others not does not break any of them.
What CPDB adds is full support for the New Architecture, especially
1. No direct handling of the print queue's PPD files, for that printer
properties and options are only polled from CUPS through standard APIs
of libcups. Now download or local file access of the PPD file, no use of
libcups functions to handle PPD files.
2. The dialog lists (and also prints on) not only permanent CUPS queues
whic the user or admin creates, but also IPP print destinations for
which CUPS does not need a permanent print queue, where, when one tries
to print, CIUPS auto-creates a temporary queue and removes this queue
again when the job is done.
To fulfill this, one has to use the newest, up-to-date (already for
several years) CUPS API, the cups...Dest...() functions of libcups, like
cupsEnumDests() to list available print destinations, both classic,
permanent CUPS queues and IPP print destinations.
The CPDB CUPS backend does this.
The other advantage of CPDB is that we maintain the CUPS backend at
OpenPrinting and when something else changes in CUPS we will update the
backend, and so the CPDB-supporting print dialogs stay up-to-date.
Generally for print dialogs to work they only need to fulfill (1) and
(2), usually by using the correct cups...Dest...() libcups API. If a
dialog misses CPDB but fulfills these criteria on its own, we are good
enough, for now at least.
The workaround for print dialogs which do not comply is cups-browsed.
cups-browsed, as it is pre-configured in the Ubuntu (and with this also
in the identical Debian) package generates a classic, permanent CUPS
queue (with a PPD file) for each discovered IPP print destination on
which CUPS would print with a temporary queue. So even print dialogs
which fail on both (1) and (2) will work.
With CUPS 2.x one can always use cups-browsed, even with the CUPS Snap
(as long as it is still CUPS 2.x). With CUPS 3.x the current
cups-browsed will not work any more, as we cannot create classic queues
with PPD files any more. cups-browsed will then be replaced by a Printer
Application (Cluster Printer Application? cluster-printer-app?) which
continues its clustering functionality, but this one will not make
outdated print dialogs working.
I want to get rid of installing and running cups-browsed by default.
What we can do for the time being until we actually get CUPS 3.x (Mike
has postponed it by a year, to end-2024, see my May News) is to make
Debian packages containing not-complying print dialogs depend on
cups-browsed (or at least recommend it): libgtk3, Qt4, Qt5, apps with
their own print dialogs until those adopt CPDB. The (better)
alternatives for old versions of the GUI libraries GTK and Qt is to
backport the CPDB support of the current version, perhaps even as distro
patch.
Apps with their own print dialogs often allow to click a button in the
app's print dialog to open the "standard" or "system" print dialog,
which is the GTK one. If that GTK dialog is GTK4 (CPDB support) or of a
GTK with backported CPDB support, we could distro-patch the app top not
show its own dialog at all but the GTK print dialog straight away.
For the NEW packages I suggest the following:
Jeremy and/or Seb upload/propose the new packages so that Thorsten,
who is then allowed to review the additions, reviews them as a person
who knows well about Linux printing. If Thorsten would upload them it
would get difficult to find a reviewer.
Oh, what do you mean by reviewer and especially what reviewer with
knowledge about printing? May I have no packaging fun here?
OK, perhaps I got somewhat confused here.
Jeremy told me that if a new package is added to Debian and it gets into
the NEW queue, another person than the original uploader has to review it.
Most intuitive is that, you, Thorsten, upload these new packages. But
that another person, not you has to review the new package. For sure
that person is less knowledgeable of printing than you and therefore
could take longer, make wrong decisions, ...
So we came to the idea that Jeremy and/or Seb upload the new packages
and you review them so that they get out of the NEW queue into Debian
unstable. After that we can transfer these packages to you as the
maintainer.
The uploading does not need much knowledge/experience with printing,
because the packages exist already as Ubuntu packages, created by me ...
WDYT? Thorsten? Is this needed? Otherwise you could upload them
straight-away.
Till
