Le Tuesday 02 November 2010 03:57:40 Olaf Meeuwissen, vous avez ?crit :
> 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,
Hello,
I agree that things would be cleaner with a separate utility so that
scanimage focus would only be scanning. Currently scanimage already extends
beyond that role with the -T/--test option. The proposed patch is a short term
solution while separating test and probe functions to a separate program is a
longer term goal.
Regards,
Stef
