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

[stef]

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