Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

I have now released version 2.0b6 of cpdb-libs, with a lot of bug fixes, 
especially of crashers, and with some changes which needed to apply to ease 
sandboxed packaging (Snap, OCI containers, ...) of the backends.


This changes caused slight changes in the API, which could also cause slight 
changes to be needed in the print dialog code, mainly a different function has 
to be called to send off a print job.


I highly recommend to only work with this version and to update if an older 
version is installed.


The announcement is here:

https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-Sixth-Beta-Release/

See especially also the "API changes" section.

Gaurav (Guleria), please updated to this cpdb-libs version, test the Qt dialog, 
and do the needed changes on it for sending off the print jobs streaming and 
with a job title. If you have any code to explicitly support the CPDB FILE 
backend, for example for the user to choose the file to print into, you should 
remove it.


Further API changes will most probably not happen any more.

Once the patches being updated by Gaurav Guleria I will also look through them 
to see whether everything is done correctly. Especially with 2.0b6 it is easier 
to test everything as it has many bug fixes since 2.0b5 of 10 months ago.


   Till


On 6/18/24 10:25, Volker Hilsheimer wrote:

Hi all,

The support for Common Print Dialog Backends has been in the works for a while. 
As of last year we are provisioning the SDK in our CI nodes:

https://codereview.qt-project.org/c/qt/qt5/+/471258

but the change on Qt is stuck a bit. Could someone with experience and 
knowledge about the state of CPDB help with reviewing those patches, please? 
Open changes are in the chain at

https://codereview.qt-project.org/c/qt/qtbase/+/437301/17

(need to be rebased and the SDK might need to be bumped to latest version 
v2.0b5).

Thanks,
Volker


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Volker Hilsheimer via Development]

Hi all,

The support for Common Print Dialog Backends has been in the works for a while. 
As of last year we are provisioning the SDK in our CI nodes:

https://codereview.qt-project.org/c/qt/qt5/+/471258

but the change on Qt is stuck a bit. Could someone with experience and 
knowledge about the state of CPDB help with reviewing those patches, please? 
Open changes are in the chain at

https://codereview.qt-project.org/c/qt/qtbase/+/437301/17

(need to be rebased and the SDK might need to be bumped to latest version 
v2.0b5).

Thanks,
Volker


> On 17 Oct 2022, at 16:03, G G  wrote:
> 
> I have added CPDB support to the print dialog, and opened a pull request 
> here: https://codereview.qt-project.org/c/qt/qtbase/+/437301. It would be 
> great if anyone is able to review it.
> 
> To build qt with CPDB support, make sure you have CPDB frontend library: 
> https://github.com/openprinting/cpdb-libs and CPDB CUPS backend: 
> https://github.com/openprinting/cpdb-backend-cups installed. Their debian 
> packages are outdated, since I had to make some one time changes and 
> improvements to CPDB while adding support to the GTK and Qt print dialog. 
> Once you have both of them installed, the "configure" command should 
> automatically pick up on the CPDB backend and prefer it over the CUPS backend.
> 
> For now, I have used "#if QT_CONFIG(cpdb) ... #endif"  constructs in the UNIX 
> print backend, and also added a CPDB Job widget, which shares the same UI as 
> CUPS Job widget but different implementation. 
> 
> Thanks,
> Gaurav
> 
> 
> On Fri, Sep 16, 2022 at 3:50 AM Gaurav Guleria  wrote:
> Hello all,
> 
> I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add 
> and improve Common Print Dialog (CPD) support to existing print dialogs 
> like GTK and Qt. More about CPD can be read here: 
> https://openprinting.github.io/projects/04-print-dialog/.
> 
> I wanted to ask about your opinions on the implementation and the way we 
> should proceed with it. I talked with a few people and read this old 
> article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt 
> team prefers CPD support as a plugin rather than a direct integration 
> into the QPrintDialog.
> 
> Just to summarize briefly, implementing CPD support directly in the 
> print dialog would mean that the Qt team wouldn't have to worry about 
> any future CUPS changes, or any other print backends for that matter, as 
> CPD will handle them all instead.
> 
> It would be really helpful if you could share your views on this and 
> give your suggestions.
> 
> Thanks,
> 
> Gaurav
> 
> ___
> 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

Re: [Development] Adding CPD support to Qt print dialog

[G G]

I have added CPDB support to the print dialog, and opened a pull request
here: https://codereview.qt-project.org/c/qt/qtbase/+/437301. It would be
great if anyone is able to review it.

To build qt with CPDB support, make sure you have CPDB frontend library:
https://github.com/openprinting/cpdb-libs and CPDB CUPS backend:
https://github.com/openprinting/cpdb-backend-cups installed. Their debian
packages are outdated, since I had to make some one time changes and
improvements to CPDB while adding support to the GTK and Qt print dialog.
Once you have both of them installed, the "configure" command should
automatically pick up on the CPDB backend and prefer it over the CUPS
backend.

For now, I have used "#if QT_CONFIG(cpdb) ... #endif"  constructs in the
UNIX print backend, and also added a CPDB Job widget, which shares the same
UI as CUPS Job widget but different implementation.

Thanks,
Gaurav


On Fri, Sep 16, 2022 at 3:50 AM Gaurav Guleria 
wrote:

> Hello all,
>
> I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add
> and improve Common Print Dialog (CPD) support to existing print dialogs
> like GTK and Qt. More about CPD can be read here:
> https://openprinting.github.io/projects/04-print-dialog/.
>
> I wanted to ask about your opinions on the implementation and the way we
> should proceed with it. I talked with a few people and read this old
> article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt
> team prefers CPD support as a plugin rather than a direct integration
> into the QPrintDialog.
>
> Just to summarize briefly, implementing CPD support directly in the
> print dialog would mean that the Qt team wouldn't have to worry about
> any future CUPS changes, or any other print backends for that matter, as
> CPD will handle them all instead.
>
> It would be really helpful if you could share your views on this and
> give your suggestions.
>
> Thanks,
>
> Gaurav
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

That’s awesome, nice work Gaurav!

- Tor Arne

On 26 Sep 2022, at 18:47, Gaurav Guleria  wrote:



Yes, CPDB is just a different backend for the existing print dialog GUI. It's 
merely a different way of enumerating printers and their features.

I have already prepared a simple CPDB plugin (still requires a few changes and 
additions) which can already respond to QPrinterInfo::availablePrinters() 
queries: https://github.com/TinyTrebuchet/qtbase/commits/cpdb.

On 9/26/22 21:30, Shawn Rutledge wrote:

On 2022 Sep 26, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog.

But it was already pointed out that the widget dialog is intended to look 
exactly the same, right?  This is not a native dialog, it’s just a different 
backend that the same old widget dialog should learn how to deal with, AFAIU.  
And qprintdialog_unix.cpp is really building up the widget hierarchy for it.  
It has a complex feature set.  We haven’t been writing new widgets ourselves, 
and a few more #if’s will be less to maintain than a whole new widget-based 
dialog would be.

Refactoring into whatever plugins or QPA stuff is worth discussing, but I guess 
it will be easier to visualize the refactoring after we’ve got something that 
works.  And I haven’t dug into the implementation enough to think about whether 
anything there is reusable in Qt Quick.  QPrinterInfo is public, so I guess the 
first natural “model” for the dialog is going to end up being the list returned 
from QPrinterInfo::availablePrinters() anyway.




___
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Gaurav Guleria]

Yes, CPDB is just a different backend for the existing print dialog GUI. 
It's merely a different way of enumerating printers and their features.


I have already prepared a simple CPDB plugin (still requires a few 
changes and additions) which can already respond to 
QPrinterInfo::availablePrinters() queries: 
https://github.com/TinyTrebuchet/qtbase/commits/cpdb.


On 9/26/22 21:30, Shawn Rutledge wrote:


On 2022 Sep 26, at 16:54, Volker Hilsheimer  
wrote:


I think it will be easier to understand what abstraction we need once 
we have a patch to look at that implements CPDB support. That we 
don’t have a QPA-level abstraction for print dialogs in Qt shouldn’t 
block adding CPDB support.


However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated 
implementation of a CPDB-dialog.


But it was already pointed out that the widget dialog is intended to 
look exactly the same, right?  This is not a native dialog, it’s just 
a different backend that the same old widget dialog should learn how 
to deal with, AFAIU.  And qprintdialog_unix.cpp is really building up 
the widget hierarchy for it.  It has a complex feature set.  We 
haven’t been writing new widgets ourselves, and a few more #if’s will 
be less to maintain than a whole new widget-based dialog would be.


Refactoring into whatever plugins or QPA stuff is worth discussing, 
but I guess it will be easier to visualize the refactoring after we’ve 
got something that works.  And I haven’t dug into the implementation 
enough to think about whether anything there is reusable in Qt Quick. 
 QPrinterInfo is public, so I guess the first natural “model” for the 
dialog is going to end up being the list returned from 
QPrinterInfo::availablePrinters() anyway.



___
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

Re: [Development] Adding CPD support to Qt print dialog

[Gaurav Guleria]

I am willing to maintain the CPDB code I will add to the Qt print 
dialogs for a while. Though I am currently not familiar with the time 
commitment it will require on my end.


Also, do we currently have a maintainer for the print dialogs?

Regards,
Gaurav Guleria

On 9/26/22 20:57, Tor Arne Vestbø wrote:



On 26 Sep 2022, at 17:19, Till Kamppeter  wrote:

But we must also take into account that Gaurav has not arbitrarily much time. 
His GSoC project is already in the extension. So he needs to know now how he 
can get CPDB support in quickly, especially without need to design a new GUI 
and to create the code for all ins and outs of a print dialog.

Will Gaurav maintain the code if added to the existing print dialogs? If not, I 
guess it’s up to the maintainer of the print dialogs whether they want to take 
on the additional technical debt.

Cheers,
Tor Arne


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 26, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog.

But it was already pointed out that the widget dialog is intended to look 
exactly the same, right?  This is not a native dialog, it’s just a different 
backend that the same old widget dialog should learn how to deal with, AFAIU.  
And qprintdialog_unix.cpp is really building up the widget hierarchy for it.  
It has a complex feature set.  We haven’t been writing new widgets ourselves, 
and a few more #if’s will be less to maintain than a whole new widget-based 
dialog would be.

Refactoring into whatever plugins or QPA stuff is worth discussing, but I guess 
it will be easier to visualize the refactoring after we’ve got something that 
works.  And I haven’t dug into the implementation enough to think about whether 
anything there is reusable in Qt Quick.  QPrinterInfo is public, so I guess the 
first natural “model” for the dialog is going to end up being the list returned 
from QPrinterInfo::availablePrinters() anyway.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 26 Sep 2022, at 17:19, Till Kamppeter  wrote:
> 
> But we must also take into account that Gaurav has not arbitrarily much time. 
> His GSoC project is already in the extension. So he needs to know now how he 
> can get CPDB support in quickly, especially without need to design a new GUI 
> and to create the code for all ins and outs of a print dialog.

Will Gaurav maintain the code if added to the existing print dialogs? If not, I 
guess it’s up to the maintainer of the print dialogs whether they want to take 
on the additional technical debt.

Cheers,
Tor Arne 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

But we must also take into account that Gaurav has not arbitrarily much 
time. His GSoC project is already in the extension. So he needs to know 
now how he can get CPDB support in quickly, especially without need to 
design a new GUI and to create the code for all ins and outs of a print 
dialog.


   Till

On 26/09/2022 17:05, Tor Arne Vestbø wrote:


Yeah, the print dialogs are much more coupled to the print engines than 
I initially thought/expected. I agree that a separate dialog is 
preferable to adding even more #ifdefs to the existing unix dialog. Then 
we have a basis for possible future abstractions.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

On 26 Sep 2022, at 16:54, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:



On 25 Sep 2022, at 20:58, Albert Astals Cid 
mailto:aa...@kde.org>> wrote:

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 
mailto:gaurav.g...@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

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog. Or rather two implementations, as Shawn has pointed out: one for 
Qt Widgets and one for Qt Quick. And if those two are then based on a common 
abstraction that provides the logic and is informed by what we already have in 
QAbstractPrintDialog - but without the dependency to Qt Widgets - then that 
might perhaps become a basis for what we want in QPA.

Yeah, the print dialogs are much more coupled to the print engines than I 
initially thought/expected. I agree that a separate dialog is preferable to 
adding even more #ifdefs to the existing unix dialog. Then we have a basis for 
possible future abstractions.

Cheers,
Tor Arne

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Volker Hilsheimer]

> On 25 Sep 2022, at 20:58, Albert Astals Cid  wrote:
> 
> 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 
>>> 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

I think it will be easier to understand what abstraction we need once we have a 
patch to look at that implements CPDB support. That we don’t have a QPA-level 
abstraction for print dialogs in Qt shouldn’t block adding CPDB support.

However, rather than throwing more #if’ery complexity into 
qprintdialog_unix.cpp it might be best to make a dedicated implementation of a 
CPDB-dialog. Or rather two implementations, as Shawn has pointed out: one for 
Qt Widgets and one for Qt Quick. And if those two are then based on a common 
abstraction that provides the logic and is informed by what we already have in 
QAbstractPrintDialog - but without the dependency to Qt Widgets - then that 
might perhaps become a basis for what we want in QPA.

Cheers,
Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Albert Astals Cid]

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




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria  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.

Cheers,
Tor Arne

> 
> On 9/19/22 21:59, Tor Arne Vestbø wrote:
>> 
>>> On 19 Sep 2022, at 18:21, Till Kamppeter  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

Re: [Development] Adding CPD support to Qt print dialog

[Gaurav Guleria]

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

Re: [Development] Adding CPD support to Qt print dialog

[Albert Astals Cid]

El dilluns, 19 de setembre de 2022, a les 14:59:46 (CEST), Shawn Rutledge va 
escriure:
> On 2022 Sep 19, at 12:38, Till Kamppeter
> mailto:till.kamppe...@gmail.com>> wrote:
 
> On 16/09/2022 08:32, Shawn Rutledge wrote:
> But Qt has its own D-Bus implementation, so we tend to prefer using that,
> rather than using some external library that uses some other library that
> talks to D-Bus.  But if you really want to use the library, maybe /that/
> could be a reason to do dynamic loading?
 
> A re-implementation of the frontend part of CPDB with Qt's D-Bus
> implementation to overcome the need of two different libraries for D-Bus
> access in the whole Qt print dialog would lead to a maintenance overhead.
> Any change in the D-Bus interface in the original OpenPrinting
> implementation needs to get reflected in the Qt implementation.
 
> Yes, but do you think it needs any changes?  It’s been a few years.  The
> D-Bus interface is a kind of contract, usually you want to be sure you got
> that right.
 
> We still don’t have a print dialog in Qt Quick Dialogs, and I think we need
> to add one within the next couple of years (if we get around to defining
> how printing is supposed to work; I have a reasonable idea for that, I
> think, but nobody has implemented anything like that AFAIK).  So we do need
> a nice interface, suited to implementing that kind of dialog.
 
> And what is the print dialog we see opened by Qt/KDE apps then? Where does
> it come from?
 
> Have you seen a Qt Quick print dialog?  Most likely it’s still only widget
> applications that have printing functionality, and use QPrintDialog or the
> one that’s described here:
> https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog  But I
> don’t know for sure.

There has not been a KDE print dialog for decades at this point that tutorial 
is KDE 4 and it still basically gave you a regular QPrintDialog with 
potentially some custom tabs.

https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/4.14/kdeui/dialogs/kdeprintdialog.cpp#L44

Cheers,
  Akbert


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 18:21, Till Kamppeter  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

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

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



The second is to throw the backend concept of the Qt dialog over board and 
replace it by CPDB, the Qt print dialog itself using cpdb-libs to connect to 
backends, which are now only the CPDB backends, no Qt print backends any more. 
By conditional compiling one could decide here at build time to use the CPDB 
concept, the old Qt print backend concept, or both (and in that case which has 
priority).


This can only be done if CPDB is available on all platforms Qt supports.


OK, so replacing Qt's backend concept by CPDB would only work under 
Linux, requiring conditionals to stay with the Qt concept for other 
platforms. So we stay with the approach of implementing the CPDB support 
in a Qt print backend/plugin.


   Till
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 19/09/2022 14:59, Shawn Rutledge wrote:
A re-implementation of the frontend part of CPDB with Qt's D-Bus 
implementation to overcome the need of two different libraries for 
D-Bus access in the whole Qt print dialog would lead to a maintenance 
overhead. Any change in the D-Bus interface in the original 
OpenPrinting implementation needs to get reflected in the Qt 
implementation.


Yes, but do you think it needs any changes?  It’s been a few years.  The 
D-Bus interface is a kind of contract, usually you want to be sure you 
got that right.




I think, once Gaurav having done the 2 dialogs, GTK and Qt, the D-Bus 
interface should be rather stable, as with the 2 dialogs we know our 
needs more or less. Then an implementation in Qt D-Bus could be done.


Have you seen a Qt Quick print dialog?  Most likely it’s still only 
widget applications that have printing functionality, and use 
QPrintDialog or the one that’s described here: 
https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog 
 
But I don’t know for sure.




No, I did not actually know which variants of print dialog exist for 
Qt/KDE and where they actually come from. If there is only Qt and 
nothing more, is there already a print dialog readily available?


[...]

Does this mean that we make the Qt/KDE apps use the GTK print dialog 
for which Gaurav has already done the CPDB support? Would be a lot of 
library overhead for pure KDE/Qt distros or for containerized apps.


No, but it should probably end up similar to the behavior with the file 
dialog: if you are running Gnome, and a Qt application creates a 
QFileDialog, on your desktop you will see a GTK file dialog instead. 
  That way you have a consistent desktop experience across applications. 
  That checking happens at runtime here:


https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp#n838 



|if (d->canBeNativeDialog()) { if (d->setNativeDialogVisible(visible)) { ...|



So this would look like in Flatpak where the app connects to the portal 
and the desktop opens the dialog (KDE app under GNOME -> GNOME dialogs).



Our CPDB support should work in all Qt apps not only in KDE apps.


Obviously; but if KDE developers want to start making any customized 
print dialogs, they may depend on some things that we are adding; or if 
they are already working on it, it would be good to find out.


If the CPDB support would be simply another backend for the Qt print 
dialog, would it then also work with these customized KDE dialogs?


   Till

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Tor Arne Vestbø]

> On 19 Sep 2022, at 00:51, Till Kamppeter  wrote:

> We do not do any GUI design or change as part of our project. We only add a 
> new method to obtain the available printers, their capabilities and options, 
> and to send off print jobs to them.

That’s good news.

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

> The second is to throw the backend concept of the Qt dialog over board and 
> replace it by CPDB, the Qt print dialog itself using cpdb-libs to connect to 
> backends, which are now only the CPDB backends, no Qt print backends any 
> more. By conditional compiling one could decide here at build time to use the 
> CPDB concept, the old Qt print backend concept, or both (and in that case 
> which has priority).

This can only be done if CPDB is available on all platforms Qt supports.

Cheers,
Tor Arne
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 19, at 12:38, Till Kamppeter 
mailto:till.kamppe...@gmail.com>> wrote:

On 16/09/2022 08:32, Shawn Rutledge wrote:
But Qt has its own D-Bus implementation, so we tend to prefer using that, 
rather than using some external library that uses some other library that talks 
to D-Bus.  But if you really want to use the library, maybe /that/ could be a 
reason to do dynamic loading?

A re-implementation of the frontend part of CPDB with Qt's D-Bus implementation 
to overcome the need of two different libraries for D-Bus access in the whole 
Qt print dialog would lead to a maintenance overhead. Any change in the D-Bus 
interface in the original OpenPrinting implementation needs to get reflected in 
the Qt implementation.

Yes, but do you think it needs any changes?  It’s been a few years.  The D-Bus 
interface is a kind of contract, usually you want to be sure you got that right.

We still don’t have a print dialog in Qt Quick Dialogs, and I think we need to 
add one within the next couple of years (if we get around to defining how 
printing is supposed to work; I have a reasonable idea for that, I think, but 
nobody has implemented anything like that AFAIK).  So we do need a nice 
interface, suited to implementing that kind of dialog.

And what is the print dialog we see opened by Qt/KDE apps then? Where does it 
come from?

Have you seen a Qt Quick print dialog?  Most likely it’s still only widget 
applications that have printing functionality, and use QPrintDialog or the one 
that’s described here: 
https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog  But I 
don’t know for sure.

 I don’t see any “dialog helpers” for print dialogs yet; 
qtbase/src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.h doesn’t have a GTK 
print dialog.  Other Qt Quick Dialogs like 
https://doc.qt.io/qt-6/qml-qtquick-dialogs-filedialog.html 
 use such helpers 
to show native platform dialogs, and we also have QML/Qt Quick Controls 
implementations of the same dialogs that are designed to look like (or better 
than) the widget dialogs.  (A Qt Quick application should never need to load 
the widget library, for any of its functionality.  That’s a goal… not always 
achieved so far. https://doc.qt.io/qt-6/qtlabsplatform-index.html 
 exists for the few cases 
when widgets are still needed, and we are actively trying to shrink that module 
by finding ways to implement the same functionality without widget 
dependencies.)
So I think there are several areas to start work in:
- a Qt D-Bus implementation of the CPDB interface

Probably the simplest to overcome the glib-D-Bus library overhead.

- add code to src/printsupport/dialogs/qprintdialog_unix.cpp to use that D-Bus 
implementation (wrapped with #if QT_CONFIG(cpdb) or whatever, and without 
removing other functionality for now)

What do you mean here exactly? Using cpdb-libs with its D-Bus access if the 
code enclosed by #if QT_CONFIG(cpdb) is used?

- some QPA abstraction that a QML-implemented PrintDialog can use: that 
probably includes a QAbstractItemModel or QAbstractListModel subclass for the 
list of printers, maybe another model for the choices that a particular printer 
can present to the user, and so on
- add the GTK print dialog helper; that’s unrelated to the rest, but when we 
add a QML PrintDialog, we may want to have the usual “native dialog” 
alternative; and perhaps it already uses CPDB?  Users of Gnome and other 
GTK-based desktops will expect it, but almost nobody else.

Does this mean that we make the Qt/KDE apps use the GTK print dialog for which 
Gaurav has already done the CPDB support? Would be a lot of library overhead 
for pure KDE/Qt distros or for containerized apps.

No, but it should probably end up similar to the behavior with the file dialog: 
if you are running Gnome, and a Qt application creates a QFileDialog, on your 
desktop you will see a GTK file dialog instead.  That way you have a consistent 
desktop experience across applications.  That checking happens at runtime here:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/dialogs/qfiledialog.cpp#n838

if (d->canBeNativeDialog()) {
if (d->setNativeDialogVisible(visible)) { ...

- add print dialog helpers to all other platforms where it’s possible (macOS, 
Windows, iOS/iPadOS, Android, …?)

We need CPDB only for Linux and similar OSes not for Windows?mac/Android/iOS.

Sure, the point was just that those platforms might need new dialog helpers 
too, similar to the GTK dialog helper, but using the respective native APIs.  
That’s work for us to try to get around to some day (or some interested 
volunteer).

- work with KDE, sync up with their approach to this

Our CPDB support should work in all Qt apps not only in KDE apps.

Obviously; but if KDE developers want to start making any customized print 
dialogs, they may depend on some things that we 

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 16/09/2022 08:32, Shawn Rutledge wrote:


Along with Chris, I’m wondering why you think it should be a plugin.

Anyway it seems some misunderstandings are possible.  Lars wrote "code 
that uses the CPDB dialogs instead of our own implementations”… but are 
there replacement GUI dialogs? The web site says it’s about "separating 
the print dialogs of different GUI toolkits and applications (GTK, Qt, 
LibreOffice, …) from the different print technologies (CUPS/IPP, Google 
Cloud Print, …) so that they can get developed independently”.  And they 
use D-Bus.  Here are the current D-Bus specifications (which have been 
modified recently): 
https://github.com/OpenPrinting/cpdb-libs/tree/master/cpdb/interface 
 So now 
it seems we bump into the typical GTK/glib pattern that they like to 
provide a stable C interface, as a higher priority than a 
stable D-Bus interface.  But Qt has its own D-Bus implementation, so we 
tend to prefer using that, rather than using some external library that 
uses some other library that talks to D-Bus.  But if you really want to 
use the library, maybe /that/ could be a reason to do dynamic loading?




First, as I told already in my answer to Lars' post in this thread, we 
do not create a new print dialog, no GUI design and change needed. We 
only change the method how the already existing Qt dialog obtains 
available printers, their cpabilities and options, and send print jobs. 
We move the communication with the print technologies (CUPS, 
print-to-file, cloud printing, ...) into separate D-Bus-coupled modules 
which get maintained by the maintainers of each print technology, 
removing the burden of keeping the print dialogs up-to-date with changes 
in the print technologies from the GUI toolkit developers.


The CPDB frontend library in the cpdb-libs package contains a D-Bus 
interface to communicate with the modules (the backends) and an API for 
the print dialogs (the frontends) on its other end.


The easiest way to obtain CPDB support in a print dialog is just using 
cpdb-libs, not caring about what the library does internally (in our 
case using D-Bus). This is also the safest way to keep everything 
working should the internals of CPDB change (modifications in the D-Bus 
interface or even replacing the D-Bus connection by something completely 
different).


The problem that cpdb-libs and Qt use different D-Bus 
implementations/libraries is best to overcome by having the CPDB support 
in a dynamically loaded Qt print backend and not directly in the Qt dialog.


A re-implementation of the frontend part of CPDB with Qt's D-Bus 
implementation to overcome the need of two different libraries for D-Bus 
access in the whole Qt print dialog would lead to a maintenance 
overhead. Any change in the D-Bus interface in the original OpenPrinting 
implementation needs to get reflected in the Qt implementation.


On most Linux distros, Qt gets installed as normal packages, so it’s up 
to the packagers to ensure that Qt’s dependencies shall be installed as 
pre-requisites.  In that case, if it ends up that cpdb-lib is a 
dependency, and it gets installed automatically, that’s fine.


Linux distros are not such a problem. They will come with cpdb-libs and 
auto-install it if an installed print dialog or app needs it.


But 
commercial applications, and applications on other operating systems, 
tend to get developed with a version of Qt that comes from the Qt 
installer, so then dependency management is trickier, and we sometimes 
use dynamic loading of “iffy” libraries that may or may not already be 
installed.  (But if CPDB really becomes universal, then maybe within a 
few years we could assume that it’s always installed.)




Yes, here dynamic loading would be the solution, either cpdb-libs itself 
or the CPDB Qt print backend.


Sandboxed packages, like Snaps, must contain cpdb-libs to support CPDB, 
and they must be set to allowthe encapsulated application to access the 
host systems D-Bus.


If you’d develop with Qt D-Bus https://doc.qt.io/qt-6/qtdbus-index.html 
 you would not have a library 
dependency problem; but instead, you’d have the problem that the D-Bus 
interface for this service may change, that requires maintenance, and 
someone has to follow along with the changes that are being done in 
cpdb-lib, so that our implementation keeps working like theirs does. 
  But so far, we are getting away with this approach in other cases, 
such as the AppMenu and StatusNotifier interfaces.  So I think I’d still 
try to do it that way; I just hope they don't break compatibility often. 
  GTK/glib people may say they want to be able to break compatibility at 
any time, but to me it doesn’t make sense to say that an interface 
/specification/ is more fluid than a C interface that implements it. 
  The XML has to be published and versioned.  When it’s stable, both the 
C and 

Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

On 16/09/2022 07:32, Lars Knoll wrote:


But the native print dialogs do currently all live inside Qt print support, so 
I don’t see why we shouldn’t add one more.


Lars, note that we do not create a new print dialog here. We do not do 
any GUI design or change as part of our project. We only add a new 
method to obtain the available printers, their capabilities and options, 
and to send off print jobs to them.


Common Print Dialog Backends (CPDB, 
https://openprinting.github.io/achievements/#common-print-dialog-backends), 
not to be confused with the earlier Common Print Dialog (CPD, 
https://openprinting.github.io/achievements/#common-print-dialog) 
approach, is about having **GUI-toolkit-independent**, D-Bus-coupled 
backends to communicate with the different print technologies (CUPS, 
print-to-file, cloud printing services, ...), so that the responsibility 
about this communication moves from the GUI toolkit developers (or app 
developers) to the developers of the print technologies (OpenPrinting, 
cloud service providers, ...).


We want to make a CPDB frontend out of the Qt print dialog (we have 
already done so with the GTK print dialog). For this we have principally 
two ways to do it:


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.


The second is to throw the backend concept of the Qt dialog over board 
and replace it by CPDB, the Qt print dialog itself using cpdb-libs to 
connect to backends, which are now only the CPDB backends, no Qt print 
backends any more. By conditional compiling one could decide here at 
build time to use the CPDB concept, the old Qt print backend concept, or 
both (and in that case which has priority).


The first solution gives full flexibility at run time, especially if in 
a distro the cpdb-libs are available but not installed by default. 
Distros not providing cpdb-libs are also not a problem here, as there is 
no hard dependency on them for the Qt print dialog itself.


The second solution has the advantage of a deeper integration of the 
CPDB concept in the Qt print dialog as Qt's own print dialog backend 
interface could not get a bottle neck. But we get a hard dependency on 
cpdb-libs already at build time.


I will release cpdb-libs 2.0 ASAP, meaning when Gaurav has both dialogs 
working well enough and so I know about the completeness of the API.


Then distros will adopt the CPDB concept as we have all components 
available: GTK and Qt print dialogs, cpdb-libs, and CUPS and 
print-to-file CPDB backends, the CUPS backend following the PPD-less 
all-IPP architecture, allowing a smooth transition into CUPS 3.x.





Just to summarize briefly, implementing CPD support directly in the
print dialog would mean that the Qt team wouldn't have to worry about
any future CUPS changes, or any other print backends for that matter, as
CPD will handle them all instead.


I am unsure whether we can get rid of CUPS and replace it with CPD, or whether 
we will need both side by side (and select the supported one at runtime). 
What’s the status here, are all Linux distributions nowadays supporting CPD? If 
yes, then we can either remove CUPS, or at least turn it into a compile time 
configuration option.


The distros do not use CPDB by default currently as current print 
dialogs do not use CPDB. Libraries and backends are available in some 
distro's optional package repositories, like for example in Ubuntu's 
Universe.


The switchover to CPDB is our way to get into the New Architecture, 
PPD-less, all-IPP printing. The CUPS CPDB backend is already made for 
this and if print dialogs adopt CPDB they are working correctly with the 
New Architecture. The current CUPS also works with all-IPP clients 
without PPD support. So once CPDB-enabled print dialogs are in place the 
transition from CUPS 2.x to CUPS 3.x will be completely transparent for 
users.


The easiest transition for the Qt dialog from using its own CUPS backend 
to using CPDB (built-in or as backend) is to have Qt at least 
temporarily support both, also supporting both makes it easier for 
ditribution of distro-independent binary packages, like commercial Qt 
applications, so that they fit into both classic and CPDB system 
environments.


If the Qt in use by an app supports both and also the system supports 
both (CUPS is installed, the cUPS CPDB backend is installed, CPDB should 
get prioritized.


   Till
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 16, at 11:13, JiDe Zhang mailto:zc...@live.com>> 
wrote:

Whether or not CPD should be implementation in Qt, we can first add some QPA 
abstraction for Print Dialog like as File Dialog. If the implementation of XDG 
portal in desktop environment is supported CPD, and Qt supported 
org.freedesktop.portal.Print, then we can use CPD in Qt applications.

Yes, and if that and 
org.freedesktop.portal.Print<https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Print>
 are both available (which we could check by introspecting d-bus, although I’m 
not sure if that’s the first choice), I guess the maximum number of choices 
would be between a dialog helper for the portal dialog, another one for GTK, 
QPrintDialog (the actual widget implementation), and a QML implementation?

QFileDialog::DontUseNativeDialog is an option, and the docs explain "By 
default, the native file dialog is used unless you use a subclass of 
QFileDialog that contains the Q_OBJECT macro, or the platform does not have a 
native dialog of the type that you require.”  (Scribus is an example of an 
application that adds features to their version of QFileDialog, so they really 
want to use that one, not the native one.  
https://github.com/scribusproject/scribus/blob/6078676dff094fa9f0ffedf2170a6c7b5112de23/scribus/ui/scfilewidget.h)
  So I guess we should follow the same pattern in QPrintDialog?  It has 
options, but not that one.  If the option exists but is not set, it would be ok 
for QPrintDialog to use the native dialog by default, if possible.  (And we 
don’t encourage anyone to instantiate a dialog and then modify it 
programmatically, that’s not really the purpose of that flag.)  So widget apps 
don’t need to change anything, just keep using QPrintDialog.

A few years ago I did some refactoring in QFileDialog, because early in Qt 5 it 
was still instantiating all the widgets that make up the dialog, even if you 
ended up showing the native one instead.  (Some of those widgets needed to 
exist because they were holding state.  That was weird.)  So let’s not repeat 
that mistake either.  ;-)  https://codereview.qt-project.org/c/qt/qtbase/+/67510

So yeah, these could take pressure off from needing to change 
qprintdialog_unix.cpp to actually populate itself a different way, but maybe it 
should still be done eventually.


From: Development 
mailto:development-boun...@qt-project.org>> 
on behalf of Ilya Fedin mailto:fedin-ilja2...@ya.ru>>
Sent: Friday, September 16, 2022 14:56
To: development@qt-project.org<mailto:development@qt-project.org> 
mailto:development@qt-project.org>>
Subject: Re: [Development] Adding CPD support to Qt print dialog

On Fri, 16 Sep 2022 06:32:38 +
Shawn Rutledge mailto:shawn.rutle...@qt.io>> wrote:

> Another aspect that I haven’t kept up with very well is how
> containerized applications should do printing.  We have “portal”
> support for file dialogs, for example, but is CPDB intended to work
> the same way regardless whether the app has such security
> restrictions or not?  For that matter, as a design principle, is
> everyone still sure that the way for an application to reach outside
> its container is D-Bus interfaces that are designed to be trusted?
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.gnome.org%2Fmclasen%2F2018%2F07%2F19%2Fflatpak-a-look-behind-the-portal%2Fdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Bv3C78qNStklLcgcdZQ5UGMG3wJHRYKLxJ9xJ13cmmo%3Dreserved=0

There's Print portal for that purpose:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflatpak.github.io%2Fxdg-desktop-portal%2F%23gdbus-org.freedesktop.portal.Printdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hcj6nnNUiO0Nlg17slHmpO4FcD0CWB%2FMUJR1%2BNlx5qk%3Dreserved=0

What good about it is it shows native file dialogs provided by the
environment that comes as a portal backend daemon. Just like the
FileDialog portal, it doesn't matter for the portal whether the
application is actually sandboxed, so it could be used even in
non-sandboxed environment.
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopmentdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C

Re: [Development] Adding CPD support to Qt print dialog

[JiDe Zhang]

Whether or not CPD should be implementation in Qt, we can first add some QPA 
abstraction for Print Dialog like as File Dialog. If the implementation of XDG 
portal in desktop environment is supported CPD, and Qt supported 
org.freedesktop.portal.Print, then we can use CPD in Qt applications.


From: Development  on behalf of Ilya Fedin 

Sent: Friday, September 16, 2022 14:56
To: development@qt-project.org 
Subject: Re: [Development] Adding CPD support to Qt print dialog

On Fri, 16 Sep 2022 06:32:38 +
Shawn Rutledge  wrote:

> Another aspect that I haven’t kept up with very well is how
> containerized applications should do printing.  We have “portal”
> support for file dialogs, for example, but is CPDB intended to work
> the same way regardless whether the app has such security
> restrictions or not?  For that matter, as a design principle, is
> everyone still sure that the way for an application to reach outside
> its container is D-Bus interfaces that are designed to be trusted?
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.gnome.org%2Fmclasen%2F2018%2F07%2F19%2Fflatpak-a-look-behind-the-portal%2Fdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=Bv3C78qNStklLcgcdZQ5UGMG3wJHRYKLxJ9xJ13cmmo%3Dreserved=0

There's Print portal for that purpose:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflatpak.github.io%2Fxdg-desktop-portal%2F%23gdbus-org.freedesktop.portal.Printdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=hcj6nnNUiO0Nlg17slHmpO4FcD0CWB%2FMUJR1%2BNlx5qk%3Dreserved=0

What good about it is it shows native file dialogs provided by the
environment that comes as a portal backend daemon. Just like the
FileDialog portal, it doesn't matter for the portal whether the
application is actually sandboxed, so it could be used even in
non-sandboxed environment.
___
Development mailing list
Development@qt-project.org
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopmentdata=05%7C01%7C%7Ca0b26386402a4cc52feb08da97b0e52d%7C84df9e7fe9f640afb435%7C1%7C0%7C637989083255289842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=s3IG2h%2FEVUDio0QFANi3TDd1UGj5QJce3hXWRiWSVPI%3Dreserved=0
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Ilya Fedin]

On Fri, 16 Sep 2022 06:32:38 +
Shawn Rutledge  wrote:

> Another aspect that I haven’t kept up with very well is how
> containerized applications should do printing.  We have “portal”
> support for file dialogs, for example, but is CPDB intended to work
> the same way regardless whether the app has such security
> restrictions or not?  For that matter, as a design principle, is
> everyone still sure that the way for an application to reach outside
> its container is D-Bus interfaces that are designed to be trusted?
> https://blogs.gnome.org/mclasen/2018/07/19/flatpak-a-look-behind-the-portal/

There's Print portal for that purpose:
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Print

What good about it is it shows native file dialogs provided by the
environment that comes as a portal backend daemon. Just like the
FileDialog portal, it doesn't matter for the portal whether the
application is actually sandboxed, so it could be used even in
non-sandboxed environment.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Shawn Rutledge]

On 2022 Sep 16, at 00:20, Gaurav Guleria 
mailto:gaurav.g...@gmail.com>> wrote:

Hello all,

I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add and 
improve Common Print Dialog (CPD) support to existing print dialogs like GTK 
and Qt. More about CPD can be read here: 
https://openprinting.github.io/projects/04-print-dialog/.

I wanted to ask about your opinions on the implementation and the way we should 
proceed with it. I talked with a few people and read this old article here: 
https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt team prefers CPD support 
as a plugin rather than a direct integration into the QPrintDialog.

Just to summarize briefly, implementing CPD support directly in the print 
dialog would mean that the Qt team wouldn't have to worry about any future CUPS 
changes, or any other print backends for that matter, as CPD will handle them 
all instead.

It would be really helpful if you could share your views on this and give your 
suggestions.

And Chris refers us to an email from Lars in 2020:

On 2020 May 20, at 09:12, Lars Knoll 
mailto:lars.kn...@qt.io>> wrote:

Hi Priydarshi!

Sorry for the delayed answer.

Great to hear that you want to work on printing for Qt. All our code is in 
qtbase/src/printsupport, where we have cross-platform printing for Windows, 
macOS and CUPS. For Windows and macOS we use the native dialogs, for CUPS, we 
have our own set.

The easiest and best solution would probably be to integrate there, and have a 
configure time check for the CPDB libs, and in that case compile in code that 
uses the CPDB dialogs instead of our own implementations.

Doing the changes inside qtprintsupport (as opposed to a new Add-on) has the 
advantage that existing applications would automatically benefit from the new 
functionality.

Along with Chris, I’m wondering why you think it should be a plugin.

Anyway it seems some misunderstandings are possible.  Lars wrote "code that 
uses the CPDB dialogs instead of our own implementations”… but are there 
replacement GUI dialogs? The web site says it’s about "separating the print 
dialogs of different GUI toolkits and applications (GTK, Qt, LibreOffice, …) 
from the different print technologies (CUPS/IPP, Google Cloud Print, …) so that 
they can get developed independently”.  And they use D-Bus.  Here are the 
current D-Bus specifications (which have been modified recently): 
https://github.com/OpenPrinting/cpdb-libs/tree/master/cpdb/interface So now it 
seems we bump into the typical GTK/glib pattern that they like to provide a 
stable C interface, as a higher priority than a stable D-Bus interface.  But Qt 
has its own D-Bus implementation, so we tend to prefer using that, rather than 
using some external library that uses some other library that talks to D-Bus.  
But if you really want to use the library, maybe that could be a reason to do 
dynamic loading?

On most Linux distros, Qt gets installed as normal packages, so it’s up to the 
packagers to ensure that Qt’s dependencies shall be installed as 
pre-requisites.  In that case, if it ends up that cpdb-lib is a dependency, and 
it gets installed automatically, that’s fine.  But commercial applications, and 
applications on other operating systems, tend to get developed with a version 
of Qt that comes from the Qt installer, so then dependency management is 
trickier, and we sometimes use dynamic loading of “iffy” libraries that may or 
may not already be installed.  (But if CPDB really becomes universal, then 
maybe within a few years we could assume that it’s always installed.)

If you’d develop with Qt D-Bus https://doc.qt.io/qt-6/qtdbus-index.html you 
would not have a library dependency problem; but instead, you’d have the 
problem that the D-Bus interface for this service may change, that requires 
maintenance, and someone has to follow along with the changes that are being 
done in cpdb-lib, so that our implementation keeps working like theirs does.  
But so far, we are getting away with this approach in other cases, such as the 
AppMenu and StatusNotifier interfaces.  So I think I’d still try to do it that 
way; I just hope they don't break compatibility often.  GTK/glib people may say 
they want to be able to break compatibility at any time, but to me it doesn’t 
make sense to say that an interface specification is more fluid than a C 
interface that implements it.  The XML has to be published and versioned.  When 
it’s stable, both the C and D-Bus interfaces stop changing.  And if the world 
treats the D-Bus interface as being stable, they may feel some drag, and be 
reluctant to break compatibility; IMO that’s as it should be.

So my assumption is you don’t necessarily have to modify the design of 
QPrintDialog much, or replace it with another dialog, but rather that there 
will be a new way of populating the printers there, getting their capabilities, 
starting print jobs and so on; is that right?  If that's not true, and actually 
you need a 

Re: [Development] Adding CPD support to Qt print dialog

[Lars Knoll]

> On 16 Sep 2022, at 03:36, Chris Adams  wrote:
> 
> Hi Gaurav,
> 
> First, I want to make clear: I know nothing about printing at all,
> either in Qt or in general.
> But I did a quick archive search and found the following:
> https://lists.qt-project.org/pipermail/development/2020-May/039584.html
> 
> On Fri, Sep 16, 2022 at 8:22 AM Gaurav Guleria  wrote:
>> 
>> Hello all,
>> 
>> I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add
>> and improve Common Print Dialog (CPD) support to existing print dialogs
>> like GTK and Qt. More about CPD can be read here:
>> https://openprinting.github.io/projects/04-print-dialog/.
>> 
>> I wanted to ask about your opinions on the implementation and the way we
>> should proceed with it. I talked with a few people and read this old
>> article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt
>> team prefers CPD support as a plugin rather than a direct integration
>> into the QPrintDialog.
> 
> I might be misunderstanding his reply, but Lars seemed to suggest that
> he would have preferred CDB-related changes to live inside
> qtbase/src/printsupport rather than an add-on plugin.

That wiki page is somewhat outdated. In the end, it really depends on how the 
integration can be best handled. The goal should be that CPD support is 
transparent to the user of Qt, similar to how the native print or file dialogs 
work on other platforms. 

But the native print dialogs do currently all live inside Qt print support, so 
I don’t see why we shouldn’t add one more. 
> 
>> Just to summarize briefly, implementing CPD support directly in the
>> print dialog would mean that the Qt team wouldn't have to worry about
>> any future CUPS changes, or any other print backends for that matter, as
>> CPD will handle them all instead.

I am unsure whether we can get rid of CUPS and replace it with CPD, or whether 
we will need both side by side (and select the supported one at runtime). 
What’s the status here, are all Linux distributions nowadays supporting CPD? If 
yes, then we can either remove CUPS, or at least turn it into a compile time 
configuration option.
>> 
>> It would be really helpful if you could share your views on this and
>> give your suggestions.
> 
> Whatever path you end up taking, I wish you good luck and a successful 
> project!

Good luck with this, it would be great to see finally have CPD support for Qt.

Cheers,
Lars

> 
> Best regards,
> Chris.
> 
> 
>> Thanks,
>> 
>> Gaurav
>> 
>> ___
>> 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

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Adding CPD support to Qt print dialog

[Chris Adams]

Hi Gaurav,

First, I want to make clear: I know nothing about printing at all,
either in Qt or in general.
But I did a quick archive search and found the following:
https://lists.qt-project.org/pipermail/development/2020-May/039584.html

On Fri, Sep 16, 2022 at 8:22 AM Gaurav Guleria  wrote:
>
> Hello all,
>
> I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add
> and improve Common Print Dialog (CPD) support to existing print dialogs
> like GTK and Qt. More about CPD can be read here:
> https://openprinting.github.io/projects/04-print-dialog/.
>
> I wanted to ask about your opinions on the implementation and the way we
> should proceed with it. I talked with a few people and read this old
> article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt
> team prefers CPD support as a plugin rather than a direct integration
> into the QPrintDialog.

I might be misunderstanding his reply, but Lars seemed to suggest that
he would have preferred CDB-related changes to live inside
qtbase/src/printsupport rather than an add-on plugin.

> Just to summarize briefly, implementing CPD support directly in the
> print dialog would mean that the Qt team wouldn't have to worry about
> any future CUPS changes, or any other print backends for that matter, as
> CPD will handle them all instead.
>
> It would be really helpful if you could share your views on this and
> give your suggestions.

Whatever path you end up taking, I wish you good luck and a successful project!

Best regards,
Chris.


> Thanks,
>
> Gaurav
>
> ___
> 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

[Development] Adding CPD support to Qt print dialog

[Gaurav Guleria]

Hello all,

I am Gaurav Guleria, a GSoC student, working with Till Kamppeter to add 
and improve Common Print Dialog (CPD) support to existing print dialogs 
like GTK and Qt. More about CPD can be read here: 
https://openprinting.github.io/projects/04-print-dialog/.


I wanted to ask about your opinions on the implementation and the way we 
should proceed with it. I talked with a few people and read this old 
article here: https://wiki.qt.io/Qt-5-QtPrint, which suggests the Qt 
team prefers CPD support as a plugin rather than a direct integration 
into the QPrintDialog.


Just to summarize briefly, implementing CPD support directly in the 
print dialog would mean that the Qt team wouldn't have to worry about 
any future CUPS changes, or any other print backends for that matter, as 
CPD will handle them all instead.


It would be really helpful if you could share your views on this and 
give your suggestions.


Thanks,

Gaurav

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development