[sane-standard] Button handling (was: SANE2 proposal: split button/option)

[Étienne Bersac]

Hi

> yes. i think the sane2 draft button handling is very weird. i would
> scrap that part.

Agree. Does anyone agree with that ? (would be nice to have Oliver Rauch
point of view !).

> you simply cannot know ahead of time what all the valid values will
> be, and so you as a front-end programmer cannot encode that info into
> your program. you will be forever behind the standard.

Yes, you're right.

>  if your frontend becomes popular, then other backends will have to
> emulate the backends that you support well, rather than provide the
> best support for their hardware.

That's wrong. Backend should not bother to support frontend-specific
quirks. The same goes in the other direction. That's sad, but currently,
frontend has to bother backends quirks. 

> instead, we must find a way to have the backend expose options in a
> descriptive-enough fashion that the front-end can handle it, and we
> must try to keep all backends compliant.

I do fully agree.

> our difference i think is small but important. i have come to think
> button handling is best done in sane2 with a new capability bit, which
> requests that the front-end poll the backend for changing values.

Yes, you're right.

>  the
> TYPE of this option can be any of the normal sane types, since there
> might be integer or string or fixed point data instead of just bools.

Yes, you're right.

> the front-end can request that the user specify an action to perform
> when any button is pressed, or sensor is tripped, or even a
> combination, using the boolean logic I included previously.

Ok. Sorry for the misunderstanding i had about SANE design. I guess this
is due to english.

So, as a frontend developer, i want to handle common sensor. For
exemple, i want to wait for the user to introduce a paper in the
sheetfed before allowing the user to trigger the scan (case Q-Scan
sheetfed). Or, i wait for user to push the scan button before scanning
(case XP100 sheetfed), etc.

We should define well-known options for well-known button/sensor, and
let backends developers add unknown-options for unkown feature.

Please comment.
Étienne.
-- 
Verso l'Alto !
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.alioth.debian.org/pipermail/sane-standard/attachments/20070122/6513c368/attachment.pgp