[sane-devel] [sane-commit] [SCM] SANE backends - scanner drivers branch, master, updated. RELEASE_1_0_21-248-gaaa34de

[Olaf Meeuwissen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2010年11月02日 09:58, m. allan noah wrote:
> On Mon, Nov 1, 2010 at 8:53 PM, Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>> On 2010年11月01日 23:45, stef wrote:
>>> Le Monday 01 November 2010 14:51:59 m. allan noah, vous avez écrit :
>>>> We need a way for authors of button handling programs to figure out
>>>> what sensors a scanner exposes. Yes, they can use libsane to query the
>>>> options, but then a third user would have to install the button
>>>> daemon, just to find out if there are any sensors. I'd rather that
>>>> scanimage could tell us.
>>
>> Not sure I understand the scenario you have in mind.  Care to explain?
>> Within that scenario:
>>
>>  - How would one use scanimage to figure out what sensors a scanner exposes?
> 
> In this case- scanimage --all-options

This produces output similar to --help.  You said "we need a way for
authors of button handling programs to figure out what sensor a scanner
exposes".  Apart from the fact that one doesn't know what to look for,
parsing the --all-options output is not exactly my idea of a stable API.

>>  - How would one use libsane to do that for that matter?
> 
> get options and check the CAP bits.

The problem here is that there is no combination of CAP bits that
unambiguously identifies all sensors (and only all sensors).

>>  - Why would a button handling program need a button daemon to find out
>> if there are any sensors when using libsane if scanimage can do the same
>> thing using libsane without that button daemon?
> 
> It does not- but as I said above- the third party end user might like
> to know if his scanner exposes sensors BEFORE he installs the button
> daemon. We have no other program installed as part of sane-backends
> which can do this.

# I saw your follow-up on this.

You could make it a separate utility, similar to sane-find-scanner or
gamma4scanimage.  My point is that maybe this sensor listing stuff just
isn't a task for a program that was meant to "scan an image".  By your
reasoning, everything one might want to do with a scanner should be
added to scanimage.  Not saying that is wrong, just that it's debatable.

Back to my original question though, what "sixth sense" does scanimage
have that would require the help of a button daemon for a button
handling program that uses libsane to query the options in order to
determine the sensors a scanner exposes?  I can't think of one.

BTW, if a backend exposes sensors, it would be natural to provide a
button daemon (and handler?) together with that backend and install both.

>>  - How does this relate to button handling for non-button sensors such
>> as, for example, a paper tray empty sensor?
> 
> A sensor is a sensor, regardless of type- look at the fujitsu,
> canon_dr, genesys backends.

I had a quick look at part of the code of the backends you mentioned as
well as some other sensor/button related bits.  I realized that part of
my confusion stems from the fact that I mixed up the SANE_TYPE_BUTTON
with the device's buttons.  Thinking of the latter as push sensors made
things clearer (if you also call button daemons sensor monitors and
button handling programs event handlers).

Hope this helps,
- -- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS CORPORATION
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzPfiMACgkQt5qrxaZLMnKv8ACgnGuOfJxN/KzNXvTDHQo5ACAI
WjkAn2A8JYm6bJPj1ZgzjolDJQg0+wt0
=iTrB
-----END PGP SIGNATURE-----