Improvements of discovered devices/conection type lists in new-printer wizard, more debug output #65
Conversation
… backends as network backends When starting the wizard for adding a new printer the available printers and CUPS backends are enumerated by calling all CUPS backends in discovery mode, but in contrary to CUPS' "lpinfo -v" the bunch is devided up into two groups, first the faster local printer backends are called and the appropriate printers listed and after that the slower network printer backends. This way the local printers appear quickly in the wizard and the user can already proceed when the desired local printer shows up. The "driverless" and "bjnp" backends were missing in the list of network backends and therefore were considered local, ending up with the local backend round taking too long.
…covered printers The list of discovered printers and CUPS backends in the wizard for adding a new printer has an entry for the "bjnp" CUPS backend (backend for proprietary network protocol of some Canon printers). This entry appears when no appropriate Canon printer gets found and the entry in the list is useless. Therefore we suppress it.
…re from the same physical printer Various improvements in the PhysicalDevice class: - In each physical device record for a network device determine the IP address of the device and drop it into the _network_host field, instead of a host name. Try to determine the IP from both host names found in the URI and DNS-SD host names. With this it is much more reliable to find out whether two entries of discovered network devices come from the same physical device. - Add the URI of the first device added to a physical device record and do not change it when more devices get added. This way the record can be easily followed when debugging. - When dumping the content of a physical record with the repr() function for debugging, do not only show make, model, and serial number, but also IP, DNS-SD host name, and URI of the first device added. - Improve implementation of the "<" operator, checking for equal and, taking into account the DNS-SD host name, and making the function for separating make and model the same as in the "=" operator. - Added debug output.
…nal physical device entry In the new-printer wizard the list of discovered printers in the first wizard step is built up in several stages. To avoid duplicates in each stage the devices are not only added to the already existing physical device record but also to extra physical device record to mark them as new entries which still need to get added to the list. Before, these new physical device records were used for generating the list entry. Now we look up the original physical device entries as they can contain more information (especially IP address and host name) for the list entry. In addition, som extra debug information is logged.
…erial number matches If an HP multi-function device on USB has also fax functionality, there are also discovery entries for the "hpfax" backend of HPLIP and an additional entry for the "usb" CUPS backend. These entries have model names which differ from the printer's model name, leading to extra entries in the list of discovered printers. To join these entries we consider two HP printers as equal if they have the same serial number, regardless of the model name.
Some USB printers appear as two USB devices, one for printing and one for fax. This would lead to 2 connection types in the connection type list which are names "USB" and undistinguishable. Now we check on USB printer entries whether they are for fax and mark them as "Fax - USB".
…nection type list On a USB multi-function device the printing functionality is much more important than the fax functionality. Most users only use the printing part, and the fax part is also often not supported by an appropriate driver. So let the entry for printing appear first in the connection type list.
|
Hi Till, |
getaddrinfo() is more universal than gethostbyname(), especially it supports also IPv6. So now we also get IP addresses if the device is only available in an IPv6 network and therefore has only an IPv6 IP address.
|
zdohnal, I am TOTALLY LOST in github's user interface. I have done the fix (use getaddrinfo()) and committed it to my branch of system-config-printer) but I have no idea how to update this pull request (no Update button, nor any possibility to modify the position in the source branch) or to create a new one (I can create a pull request containing all changes of this pull request plus my new change, but it gives a hint to this pull request and no submit button). |
|
This is the additional commit. |
|
Hi Till, |
|
Till, Zdenek, yes, once you push a changes into your branch (or master), which has been previously requested to be merged in a Pull request, the pull request is updated automatically. Common practice is to create a separate branch for each pull request, but you can of course request to merge your master into upstream (as Till did in this PR). |
Let entries for USB printing appear before USB fax entries in the connection type list
On a USB multi-function device the printing functionality is much more important than the fax functionality. Most users only use the printing part, and the fax part is also often not supported by an appropriate driver. So let the entry for printing appear first in the connection type list.
When listing discovered USB devices, distinguish between printer and fax
Some USB printers appear as two USB devices, one for printing and one for fax. This would lead to 2 connection types in the connection type list which are names "USB" and undistinguishable. Now we check on USB printer entries whether they are for fax and mark them as "Fax - USB".
Consider entries for HP printers as the same physical device if the serial number matches
If an HP multi-function device on USB has also fax functionality, there are also discovery entries for the "hpfax" backend of HPLIP and an additional entry for the "usb" CUPS backend. These entries have model names which differ from the printer's model name, leading to extra entries in the list of discovered printers. To join these entries we consider two HP printers as equal if they have the same serial number, regardless of the model name.
When adding a device to the list of discovered devices, use the original physical device entry
In the new-printer wizard the list of discovered printers in the first wizard step is built up in several stages. To avoid duplicates in each stage the devices are not only added to the already existing physical device record but also to extra physical device record to mark them as new entries which still need to get added to the list.
Before, these new physical device records were used for generating the list entry. Now we look up the original physical device entries as they can contain more information (especially IP address and host name) for the list entry.
In addition, som extra debug information is logged.
Improved determining whether two discovered network printer entries are from the same physical printer
Various improvements in the PhysicalDevice class:
Suppress backend-only entry for the "bjnp" backend in the list of discovered printers
The list of discovered printers and CUPS backends in the wizard for adding a new printer has an entry for the "bjnp" CUPS backend (backend for proprietary network protocol of some Canon printers). This entry appears when no appropriate Canon printer gets found and the entry in the list is useless. Therefore we suppress it.
When adding a printer, consider also the "driverless" and "bjnp" CUPS backends as network backends
When starting the wizard for adding a new printer the available printers and CUPS backends are enumerated by calling all CUPS backends in discovery mode, but in contrary to CUPS' "lpinfo -v" the bunch is devided up into two groups, first the faster local printer backends are called and the appropriate printers listed and after that the slower network printer backends. This way the local printers appear quickly in the wizard and the user can already proceed when the desired local printer shows up.
The "driverless" and "bjnp" backends were missing in the list of network backends and therefore were considered local, ending up with the local backend round taking too long.