Interested in contributing to the project

[SinghCod3r]

Hello,

I would like to contribute to system-config-printer, especially on the Python side.

I have been contributing to OpenPrinting projects for some time and I would be happy to help with bug fixes, improvements, or other tasks in this project.

If there are any suitable issues for me, I would really appreciate your guidance.

Thank you!

@zdohnal @alexpevzner

[alexpevzner]

Hi @zdohnal,

Ayush Singh (@SinghCod3r) was one of the strongest candidates for GSoC-2026, and we unfortunately couldn't accommodate him due to limited slot availability.

He reached out to me because he’s actively looking for a Python project to contribute to. I pointed him toward the system-config-printer repository. The tool currently has a number of open issues, many of which lead to situations where a printer that could otherwise be flawlessly supported by the Linux printing stack ends up misconfigured and fails to print.

I don’t personally have the bandwidth to take on serious improvement work for this tool right now. However, if Ayush is willing to volunteer, I’d be glad to mentor his contributions—provided I have your blessing and support, as the maintainer of system-config-printer.

What are your thoughts on this?

[zdohnal]

Hi @alexpevzner and @SinghCod3r !

no problem, I'm happy to welcome people willing to contribute and work on the project - please work via MR+reviews so anyone can pitch in if there is time.

Do I have to do anything about settings? Alex, IIUC you have right to merge here as well, correct?

[SinghCod3r]

Thank you both for the warm welcome!

I appreciate the opportunity to contribute. Since I'm new to the system-config-printer codebase, could you recommend a good first issue or area to start with? I'd be happy to work on it and submit a Merge Request for review.

@zdohnal and @alexpevzner

[alexpevzner]

@zdohnal,

Do I have to do anything about settings? Alex, IIUC you have right to merge here as well, correct?

Yes, that's correct—I have merge rights here.

@SinghCod3r,

Since I'm new to the system-config-printer codebase, could you recommend a good first issue or area to start with?

I'd suggest starting with something relatively simple.

One particularly annoying problem is this: when a user presses the Add button to add a new printer, and there's a USB-connected printer that supports IPP over USB and is managed by ipp-usb, that printer appears twice—once as a USB printer (visible immediately) and again as a network printer (which only becomes visible after clicking the "Network Printer" tab).

As a result, users often don't think to look under the network printers and try to add it as a legacy USB printer instead, which most likely won't work because CUPS's USB backend conflicts with ipp-usb.

I propose changing system-config-printer's behavior as follows:

1. Printers managed by ipp-usb should appear in the configuration interface as local USB printers.
2. They should not be detected as legacy USB printers (CUPS will still report and detect them, but they should be suppressed from system-config-printer's list of legacy USB printers).

What do you think, gentlemen, about this proposal?

P.S. @SinghCod3r, if you need some technical details or help, don't hesitate to contact me via Telegram

[tillkamppeter]

First, I would like to convert this issue to a discussion, but somehow it does not work. It is not actually an issue. What do you consider, makes this issue "fixed"?

I appreciate a lot, @SinghCod3r and @alexpevzner that you will fix the bugs and perhaps also continue this project. Thanks a lot for stepping up.

I wanted to revive system-config-printer (@zdohnal had put it into maintenance mode) already for longer time, as CUPS 3.x development started and as I saw that the printer setup tools need to be adapted to the new CUPS. And system-config-printer is used by distros with any desktop environment not bringing its own printer setup tool. The environments which have their own tool are GNOME and KDE currently, COSMIC will soon have one, too (I have taken care of that).

I only did not succeed during all the time, as I never found good contributors for it, posting the project of making it ready for CUPS 3.x several times as project idea for the Google Summer of Code.

@soumyaDghosh has created Python bindings for libcups3 in the GSoC 2025, which would be the base of a conversion of system-config-printer to CUPS 3.x, but this year we did not find a good contributor to do the actual work on system-config-printer and decided to give up. And for the desktop environments which do not have a printer setup tool, I have talked with @Abd002 , contributor of the printer setup tool for COSMIC in this year's GSoC, and also his mentors at System76, whether he could design the tool so that it does not only run as module of the COSMIC Setting but also as standalone app to replace system-config-printer.

But this should not demotivate you, system-config-printer is a great tool (I have given the "intelligence", not actually AI, to it with which it selects the correct driver for a given printer, back in the late 2000s) and to have more than one tool to choose for a given task is a great advantage of open source. Users (or distro maintainers) can then choose what they prefer.

Whenever you have questions, please ask here. I am also with you and can also help on the side of CUPS 3.x.

[tillkamppeter]

One particularly annoying problem is this: when a user presses the Add button to add a new printer, and there's a USB-connected printer that supports IPP over USB and is managed by ipp-usb, that printer appears twice—once as a USB printer (visible immediately) and again as a network printer (which only becomes visible after clicking the "Network Printer" tab).

As a result, users often don't think to look under the network printers and try to add it as a legacy USB printer instead, which most likely won't work because CUPS's USB backend conflicts with ipp-usb.

I propose changing system-config-printer's behavior as follows:

1. Printers managed by `ipp-usb` should appear in the configuration interface as local USB printers.

2. They should _not_ be detected as legacy USB printers (CUPS will still report and detect them, but they should be suppressed from `system-config-printer`'s list of legacy USB printers).

What do you think, gentlemen, about this proposal?

I think this is a good idea. As long as ipp-usb is running the printers are just not accessible as classic printers, so they should not get listed as such. And listing them as local USB printer and not as network printer makes it more transparent for the user.