Please reduce the dependencies of the dbus backend

[berolinux]

KDE Plasma's print-manager relies on the system-config-printer dbus services for some functionality:

• New device notifications
• Device discovery and grouping
• Recommended driver discovery

It doesn't use the UI parts of system-config-printer (that look a bit out of place in a Plasma desktop). Nevertheless, because system-config-printer is currently quite monolithic (even scp-dbus-service.py imports Gtk and friends and their python bindings), it pulls in a large dependency chain.

It would be great if the dbus functionality relied upon by alternative UIs like plasma print-manager could be made independent of the UI portions to avoid the dependency chain (and memory usage by multiple toolkits etc).

[tillkamppeter]

The reason why printer setup tools (KDE Printer Manager, GNOME Control Center "Printers" module, and system-config-printer itself) all use the D-Bus service scp-dbus-service.py is that it contains the algorithms for assigning the right driver to a given (by make/mode or device ID) printer and to find out which reports of a discovered printer come from the same physical device. These algorithms are mostly developed by me.

In some stage of the development of system-config-printer the algorithms got separated out into a D-Bus service (not by me) so that other printer setup tools can benefit from them and even every printer setup tool finds the same driver for a given printer.

AFAIR there are some situations where the D-Bus service can pop up a dialog, for example if no driver is found for a printer and for downloading drivers from the internet in such a case. One needs to identify the cases when the service would try to pop up a dialog, a progress window, a message box, ...

Even without the functionality of that pop-up dialogs the service does great work which is useful for any printer setup tool, so that suppressing this functionality does not restrict the functionality of the D-Bus service too much..

The first approach would be, at the points where a dialog is popped up, to check at first whether GTK (and its Python bindings) is installed and only then pop up the dialog, otherwise skip this functionality.

A next step would be that in case of GTK being absent the function which would cause the dialog pop-up would return somehow the reason for the pop-up (ex.: no locally installed driver available, load from internet). This way the caller could proceed with downloading/installing drivers, or just say that for this printer there are no readily installed drivers available.

So for solving this, we need to start with finding out all situations where the D-Bus service would pop up a dialog and then add code to skip the dialog-based steps.

It is possible, but I am not sure that it is tried to download or directly install LSB-based RPM or DEB packages. these packages are discontinued in favor of Snap and OCI containers. So any pop-up call for handling these packages can get removed.

[tillkamppeter]

Also note that system-config-printer was discontinued and we are now reviving the development to make system-config-printer ready for CUPS 3.x.

See

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2024-openprinting-projects#introduction

and especially

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2024-openprinting-projects#desktop_integrationupdate_system-config-printer_for_the_new_architecture_of_printing

In this Google Summer of Code project we will make system-config-printer working with CUPS 3.x, in an all-IPP world without PPD files and with driverless printers and Printer Applications.

I have made the GSoC contributor who will do this project aware of this issue. He will probably comment here soon.

[berolinux]

Another option for the (fairly simple) dialogs that can be displayed would be to call an external application -- there's a few "dialog from shell" applications that provide the same command line interface, but use the user's preferred toolkit (e.g. Qt qarma provides the same interface as GTK zenity, and there's kdialog/xdialog/cdialog).

[berolinux]

For the authentication related dialogs (in asyncipp.py etc.), it's probably best to call pinentry, given that has supports all toolkits and has been designed keeping in mind that it's important it can't be eavesdropped on.