On Sat, 12 Mar 2022 at 20:56:38 +0000, Brian Potkin wrote:
> I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> needed when the printing system does the jobi, as you have demonstrated?
cups upstream's medium to long term plan seems to be that toolkits like
GTK and Qt should browse for mDNS printers themselves, and cups-browsed
will eventually disappear, so that the only print queues shown are the
ones manually configured in cups and the ones auto-discovered by the
toolkits' print dialogs:
The intention of CUPS upstream is that the application's print dialogs
browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
but it will take its time until all toolkit developers add the needed
functionality, and programs using old toolkits or no toolkits at all,
or the command line stay uncovered.
— https://github.com/OpenPrinting/cups-filters
In bullseye, cups-browsed is usually installed on desktop systems. The
intention seems to be that the printers discovered by cups-browsed take
precedence over the ones discovered by GTK, but in current bullseye this
doesn't work reliably, and instead both sets appear as near-duplicates
(see below).
In bullseye, if you print to the entries generated by GTK from mDNS,
then GTK will submits a PDF via IPP directly to the printer, bypassing
cups (and that doesn't always work, as seen here). In the implementation
in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
their names, GTK's fallback entries are implemented by asking the local
instance of cups to set up a temporary print queue, and then submitting
the job via IPP to that temporary queue, which seems to be more reliable
in practice.
So, if you think cups is always going to be better at IPP than GTK is,
I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
use of cups than the version currently in bullseye, are a better answer
than what GTK in bullseye is currently doing?
If the response to asking for testing of possible improvements is going
to be people characterizing GTK as irretrievably inept, then that is
not going to help me to find the time and motivation to work on making
things better (the opposite, in fact).
In particular, if the changes I'm proposing are bringing GTK closer to
what you want, which I think they are, then it seems counterproductive to
discourage me from making them. Conversely, if you think these changes are
wrong, please focus on proposing solutions rather than ascribing blame:
that's a much more effective way to motivate volunteers to do as you ask.
> If I set up a manual destination, I would be extremely annoyed if it was
> interfered with.
I believe the intention is that if there is a manually-configured queue,
then any automatically-discovered entries that can be identified as being
the same printer are ignored.
Also, if there is no manually-configured queue, but there is an
automatically-discovered entry from cups-browsed, then the intention
is that GTK uses that one, and any entries discovered by GTK that can
be identified as the same printer are ignored. So as far as I can
tell, it's aiming to do what you want: manual configuration "wins"
vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
so in each case, GTK is aiming to prioritize the cups printing system
higher than its own code path.
The reason we're seeing duplicates seems to be that they are not always
identified as being the same printer in the way that was intended. In
the implementation of that deduplication in bullseye's GTK, entries for
the same printer are not always identified as such, so you're offered
the result of GTK's mDNS discovery *in addition to* the one from cups,
instead of having the one from cups replace it. The changes between
bullseye and bookworm (proposed here as the ~mr6 and ~mr6.1 versions)
change the deduplication so that the duplicates coming from GTK's own
mDNS discovery are eliminated more reliably.
The code in the ~mr6 version (which is a direct backport from bookworm)
appears to be correct for bookworm's cups-browsed but not for bullseye's,
because the different versions of cups-browsed choose slightly different
names for mDNS-advertised printers. The change between ~mr6 and ~mr6.1
adjusts the naming used by GTK to match bullseye's cups-browsed, so
that the version coming from cups-browsed will "win" and replace what
GTK would have done in the absence of cups-browsed.
If you have a better implementation of this, great! Please talk to
upstream, preferably without insulting them ("these changes would make
xyz more reliable" is more likely to get the changes accepted than
"your implementation of xyz is awful and you should use this instead",
even if the resulting code is identical).
> Problem: it does not live up to its promises and hasn't for
> many years. It is inept.
Even if true, this is not an effective way to make volunteers do what
you say they should. At best, it's demoralizing and drives people away
from working on particular topics, or even from working on open-source
at all. At worst, it will make people actively hostile to doing what
you ask them to do, which seems counterproductive, particularly if you
know you're right.
I want contributing to Debian, GTK and open-source to be something I can
feel good about doing, not something where I put in a lot of work out
of a sense of responsibility and then get accused of incompetence. If you
value what I'm doing, then please help to create an atmosphere where
people like me don't burn out and leave.
Thanks,
smcv
