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

[Étienne Bersac]

Hi,

> we already have enough types. we can hold ints, strings, bools,
> decimals, and this unused 'button'. some scanners will provide ints or
> floats in response to a sensor or button, others will return strings.
> trust me, none of us understands all the high-level options that might
> be provided by a scanner,

That's also a pain for frontend developer. What does button option teach
to frontend ? I guess only button state i.e. pressed or not. this is
more or less a boolean. SANE 2 is based on this supposition. So why
fixed, strings and ints ? That's just make SANE confusing.

That's very strange that SANE is very very simple in its API (only 9
functions). That's very powerful ! But SANE is very complex in its
implementation : all backends have their own "options API". This sounds
like SANE standard does half the job. It lets backend dev alone, and let
frontend developers making it uniform. That's sad.

> so we can only give the low level
> 'building-blocks' that a backend author may need, and some guidelines
> to suggest extensions to the api.

I don't understand what is "building-blocks" option.

> > An "id" (i.e. lowercase + number + dashes). That's easy to use in
> > cmdline. Do you prefer typeing "adf" or "Automatic Document Feeder -
> > Front" ? :)
> 
> ok, so the id needs to match what is on the outside of the scanner.
> dont rely on the title.

Hmm. the idea is that id should uniform buttons whatever is outside the
scanner. For example, on HP all-in-one device, the buttons label are
translated by changing a big piece of plastic where all labels are
printed (with holes to let buttons stick out). Uniformize all for
frontends all buttons which says more or less "scan", "mail", "fax",
"copyp", … and store all the label variation in title sounds good.

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/20070121/63027c94/attachment.pgp