[sane-standard] Button handling (was: SANE2 proposal: split
button/option)
Étienne Bersac
bersace03 at laposte.net
Mon Jan 22 14:27:35 CET 2007
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
More information about the sane-standard
mailing list