Adding support for the Common Print Dialog Backends (CPDB)

[Till Kamppeter]

On 27/03/2024 16:22, Michael Weghorn wrote:
> 
> Are you aware of any specific reasons why distros would prefer direct use of 
> CUPS API over CPDB other than the usual packaging efforts needed for any new 
> library?
>

No.

It could only happen that some distros are perhaps not aware of CPDB and 
therefore try to go the way of directly talking with CUPs.

> 
> Even better if the approach other projects take seems to be the same one as 
> we're discussing for LibreOffice now. This should also provide a more uniform 
> user experience (same printers + options show up regardless of the 
> application/toolkit,...).
> 

Yes, if all use CPDB, options will look the same everywhere. And a cloud 
printing service could be made available in all print dialogs by installing a 
single CPDB backend.

> 
> There's the existing [1], but I don't know whether that would still be the right 
> place to report such things these days.
> 

We do not use the Linux Foundation Bugzilla any more. All our projects are on 
GitHub already for several years and we use the issue trackers of GitHub.

> 
> That sounds reasonable and shouldn't be a problem in general, but will of course 
> need a closer look into the code to see whether CUPS-related code is already 
> fairly local or currently spread all over the place right now, requiring some 
> more refactoring or reconsideration.
> 

OK. If CPDB is used it must be taken care that we nowhere talk with CUPS 
directly, as otherwise non-CUPS CPDB backends (cloud printing services) will not 
work.

> We already have various `--enable-<feature>`/`--disable-<feature>` configure 
> flags (some with autodetection if not passed explicitly) for various features. 
> Adding additional ones for those cases should be fine and fairly straightforward.
> 

The usual stuff of most projects: ./configure auto-detects presence of libraries 
and in addition have command line options for manual selection. So one can 
easily opt for CPDB (or it gets even auto-selected) when one wants to support 
CUPS 3.x.

> (Details on how to configure things at build and run time can also be discussed 
> later.)
>

OK.

    Till