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

[m. allan noah]

On 1/21/07, Étienne Bersac <bersace03 at laposte.net> wrote:
> 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.

as i said in a previous mail, some scanner's 'buttons' are more than
just boolean. older fujitsu's have a density 'wheel' that you can
turn, which gives an int.

> 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.

we need to find ways to get uniformity, we agree on this. but i think you are
trying to get it the wrong way, by proliferating existing types.

>
> > 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.

sorry, not another option, i was trying to say that i think we can do what you
need with just well-named options, and the minimum of changes to the various
types and structs in sane.

what i want from a front-end is to have a sort of logic made available on
all the options, not just the boolean pressing of 'buttons'. for instance:

if('function-wheel' == 7){mode='lineart',resolution=200}
if('button-scan') {scan(),save-to-dir='xxx'}
if('button-email') {scan(),emailto='xxx'}

> 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.

or better, for the backend to provide translations somehow?

allan