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
