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
