| Summary: | [KDE4] Improve CUPS detection in KCupsOptionsWidget | ||
|---|---|---|---|
| Product: | [I don't know] kde | Reporter: | Stefan Kiesler <heavymetal> |
| Component: | general | Assignee: | Unassigned bugs <unassigned-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Never mind, just got a hint on the Gentoo forums that this bug is already resolved in trunk: http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/dialogs/kcupsoptionswidget_p.cpp?view=log Sorry! |
Version: (using KDE 4.3.5) Compiler: gcc 4.3.4 OS: Linux Installed from: Gentoo Packages Important options are missing from the KDE4 print dialog when using a remote CUPS server instead of a local printer. KCupsOptionsWidget::cupsAvailable() only checks for a running socket on localhost:631, instead it should respect the client CUPS configuration and poll the configured server (localhost or remote). Here's the current (as of KDE 4.3.5) snippet of cupsAvailable() in /kdeui/dialogs/kcupsoptionswidget_p.cpp: bool KCupsOptionsWidget::cupsAvailable() { // Ideally we would have access to the private Qt method // QCUPSSupport::cupsAvailable() to do this as it is very complex routine, // instead just take the simplest case of if we can connect to port 631 // then assume CUPS must be running and used by Qt. QTcpSocket qsock; qsock.connectToHost("localhost", 631); bool rtn = qsock.waitForConnected() && qsock.isValid(); qsock.abort(); return rtn; }