As far as I know, the CUPS is currently implemented in Qt at two
different places: src/plugins/printsupport/cups/ and directly within the
dialog src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing
CPDB support as a plugin, does it mean that we create a similar
src/plugins/printsupport/cpdb which uses CPDB to enumerate printers
instead of CUPS? If so, what about the unix print dialog, don't we need
to add the CPDB code there too (#if QT_CONFIG(cpdb) ... #endif
constructs, just like CUPS)?
On 9/19/22 21:59, Tor Arne Vestbø wrote:
On 19 Sep 2022, at 18:21, Till Kamppeter <till.kamppe...@gmail.com> wrote:
On 19/09/2022 15:43, Tor Arne Vestbø wrote:
First is to create a new Qt print backend, what, instead of communicating directly with
CUPS, communicates with the CPDB backends. It is some kind of "middle end", on
one end being a Qt print backend and on the other end being a CPDB frontend.''
This sounds like a good first step. It doesn’t involve any of the GUI bits,
just the enumeration and communication with the various CPDB-exposed printers.
Since the QtPrintSupport module doesn’t depend on DBUS today (AFAIK), the CPDB
print backend should be a plugin.
OK, Gaurav so you should be able to provide the CPDB support as a plugin (Tor,
is this a Qt print backend like the one for CUPS for example?).
Correct. Note that for Qt 6, some of the print engines that were previously
plugins were moved into the QtPrintSupport library directly, such as the macOS
print engine, but the interface for enumerating these from Qt’s point of view
is still as print engine “plugins”. The CUPS engine is a fully standalone
plugin, so it’s a good basis for the CPDB work.
Cheers,
Tor Arne
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
