| Summary: | [KDE4] scan for _all_ searchable printer types in one go | ||
|---|---|---|---|
| Product: | [Unmaintained] kdeprint | Reporter: | Kai Lahmann <kfl> |
| Component: | general | Assignee: | KDEPrint Devel Mailinglist <kde-print-devel> |
| Status: | CLOSED UNMAINTAINED | ||
| Severity: | wishlist | CC: | jlayt |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Kai Lahmann
2004-03-01 13:15:32 UTC
This is indeed a nice idea, which is also called automatic printer discovery (and more generically "automatic service discovery"), which is currently the topic of different standard groups and which will be implemented in future CUPS versions. However, this is something that cannot be implemented for a practical reason: it would be difficult to cover all possibilities. Current mechanism relies on network scanning. Printer finding would mean scanning the entire network for many port values (and it could be virtually any port value), or scanning any Windows client for shared printers. IMO, this would be too intrusive and would take way too-much time to be user-friendly. Automatic printer discovery is something that will be implemented at low-level (in the print spooler), and which is already implemented for locally-connected printers. Relying on protocols like SLP, it will be possible to locate easily all printing service in a network, and provide a nice user-friendly interface to install a print queue. Until then, KDEPrint just provides some easy workarounds to find printers based on their type and some needed info given by the user. it would be enough to put the CUPS search, the TCP-Printer search and the SMB search together to one entry. I agree that it would be a simplification to scan for IPP, AppSocket, SMB and CUPS printers from one interface at once (but I wouldn't allow for more than 255 IP addresses at one time, due to limiting the intrusiveness). One more option is to use "scli" 0.3.1 (which now supports a "run scli scan 192.168.0.0/24" sub command), and it scans using SNMP. --- What *should* also be implemented is support for the new CUPS 1.2 backend called "snmp". This does not do "portscanning" (like currently kaddprinterwizard does), but makes an SNMP broadcast asking for all printers to respond. Responses then are used to specifically query each responding node for IPP, JetDirect and LPD support. KDEPrint in KDE3 is unmaintained and will have no more new features implemented. This request will never be implemented in KDEPrint as a result. In KDE4.2 onwards printer administration has been replaced by system-config-printer-kde which is just a front-end for the system-config-printer project and only supports printers configured through CUPS (see http://cyberelk.net/tim/software/system-config-printer/). In KDE4.0 onwards the print dialog is provided by Qt and only supports printers known to CUPS and LPD. Printer detection now lies outside KDE and only printers know to and configured through CUPS and/or LPD are supported. If CUPS does not support the required network protocol then a feature request would need to be raised with CUPS to correct this. Any issues with the new KDE front-end would require a separate request to be raised. Closing. |