[Development] Adding CPD support to Qt print dialog

Albert Astals Cid aacid at kde.org
Sun Sep 25 20:58:11 CEST 2022


El dissabte, 24 de setembre de 2022, a les 12:45:00 (CEST), Tor Arne Vestbø va 
escriure:
> > On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria <gaurav.gen3 at gmail.com>
> > wrote:
 
> > 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)?
> 
> The QCupsJobWidget is documented as "a widget to add to QPrintDialog to
> enable extra CUPS options such as Job Scheduling, Job Priority or Job
> Billing”, so I don’t think having any CPDB specific code in the UNIX print
> dialog is required as a first step to bring a CPDB print backend up.
 
> Once we get to that point we can look at possibly adding new API for the
> print engines to deal with the needs of QCupsJobWidget and the like, so
> that we don’t need CUPS/CPDB specifics in the dialog code.

The "problem" is not QCupsJobWidget, but the print dialog itself.

qprintdialog_unix.cpp and qpagesetupdialog_unix.cpp are full of
  #if QT_CONFIG(cups)

IMHO for now the same solution of adding ifdefs should be accepted for CPDB.

Ideally in the future an abstraction so that those ifdefs are not needed 
should be introduced, but I have the feeling that asking that abstraction to 
be added now is a bit of "asking too much".

Cheers,
  Albert

 > Cheers,
> Tor Arne
> 
> 
> > 
> > On 9/19/22 21:59, Tor Arne Vestbø wrote:
> > 
> >> 
> >> 
> >>> On 19 Sep 2022, at 18:21, Till Kamppeter <till.kamppeter at 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 at qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development






More information about the Development mailing list