On 2022 Sep 16, at 00:20, Gaurav Guleria <gaurav.g...@gmail.com<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 <lars.kn...@qt.io<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 different UI design, then yeah maybe it becomes tricky to have two kinds of print dialogs, or maybe it’s better to implement a Qt Quick version first. OK so what happened last time: https://openprinting.github.io/gsoc2020/02-common-print-dialog/ https://github.com/rithvikp1998/CPDv2/blob/master/common-print-dialog.pro nope there’s no Qt D-Bus there, they linked with gio-unix-2.0 glib-2.0 gobject-2.0 cpdb-libs-frontend 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/ 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. 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 - 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) - 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. - add print dialog helpers to all other platforms where it’s possible (macOS, Windows, iOS/iPadOS, Android, …?) - work with KDE, sync up with their approach to this I suppose for GSoC, probably it’s just the first two that are in scope, that’s fine. For the first one, there is a well-defined process, so don’t be afraid of it. You might get a first pass done in a few days, and I’m willing to help you figure it out if necessary. Both of those tasks could result in patches that you can submit to codereview.qt-project.org<http://codereview.qt-project.org> and then we will have support for this new D-Bus interface. (I could be wrong, since I haven’t tried to implement this. But it seems worth a try, at least.) An alternative approach might be to use libcpdb (if there are really good reasons), but let’s continue the discussion about whether that’s really the way to go.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
