On 2022 Sep 19, at 12:38, Till Kamppeter 
<till.kamppe...@gmail.com<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 
<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 
<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 are adding; or if they are 
already working on it, it would be good to find out.

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

Reply via email to