CUPS 1.2rc2, troubles during test

[Goffioul Michael]

> Of course, this kdeprint error message was designed at a time 
> when we had no idea that CUPS-1.2 would start supporting 
> printing over local domain sockets.

Indeed, KDEPrint assumes implicitely that the connection will be done
over TCP and has the form server:port. At the time it was written, there
was no mention of local domain socket. Hence, KDEPrint has some code
that is not adapted to UNIX sockets.

I think that the things to change are:
1) in kdeprint settings dialog, do not separate CUPS server and port,
but
use a simple string, which is more generic
2) if the user leave the CUPS server entry blank, kdeprint should always
use cupsGetServer() and not store it in its configuration file; this
ensures
that kdeprint could be always up-to-date when the default CUPS server is
changed by other means (i.e. editing clients.conf)
3) the way how printer-uri attribute is constructed is not adapted to
UNIX
domain; normally, this URI should be obtained from the printer listing
operation, stored in the KMPrinter object and re-used when needed.

Now I realize that using UNIX socket as CUPS server may have an impact
on
the pre-connection dirty hack that I introduced to cope with CUPS API
calls
that froze the whole kdeprint GUI. In the end, this dirty hack should be
completely removed. If the CUPS call still freezes (it's usually due to
DNS
request time-out), we may think about putting the offending call into a 
dedicated thread, but this requires some big architectural changes.

But first, I would try to do this cleaning and "live with it to see if
the
problem still occurs".

Michael.