Hi, I'm working with a (TCP/IP networked) device that supports cancelling of scans from the hardware side. The device signals the client (i.e. my backend) that the scan is cancelled.
I figured that I would just return SANE_STATUS_CANCELLED but the SANE spec says that sane_start() and sane_read() return this status after sane_cancel() was called. That notwithstanding my backend returns a SANE_STATUS_CANCELLED whenever somebody pushes the *device*'s cancel button. I've checked how some of the frontends deal with (Debian GNU/Linux, testing/unstable) this but it seems every frontend has its own idea of what to do :-( scanimage calls sane_cancel() after it gets SANE_STATUS_CANCELLED back from sane_read() --> all's well (sane-backends-1.0.18) xscanimage does the same as scanimage based on source code review (sane-frontends-1.0.14) xsane pops up a message dialog to inform the user that the scan was cancelled. After closing the dialog, nothing in particular seems to be done and you need to quit the application before the device becomes usable again (xsane-0.991) kooka spins into an infinite loop (because of incompleteness of the implementation, kdegraphics-3.5.5) Questions: 1) Is SANE_STATUS_CANCELLED the right thing to return? If not, what is? # FWIW, SANE_STATUS_EOF looks like the best alternative but will # probably lead to broken images ... 2) How should frontends behave when they get SANE_STATUS_CANCELLED when sane_cancel() was *not* called? Looking forward to your feedback, -- Olaf Meeuwissen FLOSS Engineer -- EPSON AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/ GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 Penguin's lib! -- I hack, therefore I am -- LPIC-2