Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sat 12 Mar 2022 at 23:35:25 +0000, Simon McVittie wrote:

> 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

The github text is in /usr/share/doc/cups-filters/README.gz. Note that
it dates from the time of CUPS 1.6 when CUPS could not browse DND-SD
multicasts of CUPS servers and printers, and therefore would not make
queues and printers available locally. cups-browsed became essential
to do this. Without it, printing to a metwork queue would have been
tortuous, if not impossibel.
 
> 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).

Since CUPS 1.6 the need for cups-browsed has effectively disappeared.
Its major use now is to provide auto-setup of a local queue.

However, on bullseye, the GTK dialog  is not using the correct CUPS APIs
and queues have to be manually created or auto-setup by cups-browsed.

 
> 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.

bookworm's libgtk does a much better job than buster's or bulleye's. On
bullseye the dialog displays "getting printer information" and never
does.

> 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?

I do agree with that.
 
> 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).

I did not say or imply the situation was "irretrievable". I did use
"inept"; "suboptimal" might have been better :).

> 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.

If you are referring to cups-browsed, that is correct.

> 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.

cups-browsed is not required with the GTK dialog in bookworm. #908500.

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908500

> 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.

I did not accuse you of incompetence but the demotivating sentiment
" printing is still hell on earth" called for a rebuttal.

I will finish as I did in ny first mail:

With thanks to Simon McVittie and everyone else for caring.

Regards,

Brian.






> 
> Thanks,
>     smcv