I wanted to check if the new print manager can enable/disable a printer. In the main dialog I select a printer and click on "Open Print Queue" which opens another dialog where everything is greyed out. In konsole I see the following error: Object::connect: No such slot PrintQueue::RemoveQueue() Object::connect: (receiver name: 'kde-print-queue') Reproducible: Always
Git commit 68ca15ceaff715f8d7e0eb36e26a39ecde70dd04 by Daniel Nicoletti. Committed on 22/10/2013 at 18:36. Pushed by dantti into branch 'KDE/4.11'. Fix typo in SLOT removeQueue() M +1 -1 printqueue/PrintQueue.cpp http://commits.kde.org/print-manager/68ca15ceaff715f8d7e0eb36e26a39ecde70dd04
The problem isn't fixed; I can confirm the problem with git compiled version from KDE/4.11 branch Now there is an error printed: Object::connect: No such slot PrintQueue::removeQueue() The reason for this message is that removeQueue() is declared in the public section, not in a ... slots: section. After moving this declaration into a public slots: section the problem is still present. Enabling debug messages shows: PrintQueue(28961) PrintQueueUi::getAttributesFinished: false true which means the returned printer attributes are empty. Running cups provided ipptool ipptool ipp://user@localhost/printers/hp -t /usr/share/cups/ipptool/get-printer-attributes.test returns no error Get printer attributes using Get-Printer-Attributes [PASS] /usr/share/cups/ipptool/get-printer-attributes.test Replacing EXPECT with DISPLAY in /usr/share/cups/ipptool/get-printer-attributes.test returns all available attributes, which indicates that there is something wrong on the kde-print-queue side.
This happens when using cups < 1.6, which is the default case for at least suse 12.2 KCups::Connection::request() calls ret = parseIPPVars(response, groupTag, true); with needDestName = true (second parameter). In this case parseIPPVars() uses a different code path, which requires the presence of the KCUPS_PRINTER_NAME attribute [1] /* * See if we have everything needed... */ if (needDestName && destAttributes[QLatin1String(KCUPS_PRINTER_NAME)].toString().isEmpty()) { if (attr == NULL) { break; } else { continue; } } Unfortunally the cups attributes KCUPS_PRINTER_NAME is not provided to KCupsRequest::getPrinterAttributes(const QString &printerName, bool isClass, QStringList attributes), which let parseIPPVars() return no attributes. Removing the code part at [1] or setting needDestName to false in the call to parseIPPVars() solves the problem. This regression has been introduced with commit 50077294fbe71517a8f06d39175eaff2a401f0af.
Git commit ce911a2dd45cdba056d4a0eb12a07c94e12c783a by Ralf Habacker. Committed on 04/12/2013 at 20:28. Pushed by habacker into branch 'KDE/4.11'. Fix of 'Disabled kde-printer-queue regression with cups < 1.6' This patch solves the problem by removing the variable needDestName which support has been removed in May 2013. FIXED-IN:4.11.5 M +2 -15 libkcups/KCupsConnection.cpp M +1 -2 libkcups/KCupsConnection.h http://commits.kde.org/print-manager/ce911a2dd45cdba056d4a0eb12a07c94e12c783a
Great thanks, since I've been using CUPS 1.6 for more than a year now I'd surely need to install an OpenSUSE VM, at least the API changes where quite important..