[sane-standard] Button handling

[abel deuring]

Étienne Bersac wrote:
> Hi,
> 
>>> 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.
> 
> Very nice device ! So SANE 2 standard is wrong about button handling ?

No. Allan "only" gave an example of a "UI element" _on the scanner_
that is not a button, but an switch/wheel with 6 or 8 or 9
positions. The setting of this switch is represented as an integer
when the backend asks the scanner for some status information, and
the backend passes this information up to the frontend as a
read-only option of type int; perhaps with a constraint.

A similar "UI element" is, BTW, available on new Fujitsu scanners.
Some have a simple one-digit 7-segment display for the numbers 0 to
9. The display value can be set by two buttons on the scanner, but
these buttons are not accessible by the backend (or any other
driver) -- the scanner tell the computer _only_ the displayed value.

A scan program (or frontend in Sane terminology) can for example
provide a configuration dialog which allows the user to assign the
action "send scan to email address XYZ" to the value 1; "COPY" or
"print scanned image" to the value 2, "save to file" to the value 3,
"send scan to email address ABC" to value 4 etc. The user must
perhaps "improve" the UI by using Scotch tape to glue a label onto
the scanner with explanations what each setting means.

SANE_TYPE_BUTTON is _completely_ different from the things we have
discussed so far. The name is perhaps misleading, but it means an
option that may be represented in the GUI of a frontend by a
clickable button. Several backends provide such options, a quick
grep through the source code of the backends shows that they are
used for things like "swicth lamp on/off", "calbrate now" etc.

>>> 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.
> 
> Ok, i missed something. I admit i have a trend to break the API.
> However, i want to see SANE 1 uniformized before the start of SANE 2
> development. The most lake of SANE 1 is more the well-known-option
> active documentation than API as well as HAL UDI support.

Cleanup of Sane1 options will not work. Why should anyone put much
work into cleanup of old code, when you can expect that work on new
code will start quite soon?

>> 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'}
> 
> That's quite simple as you expose it, however, you forgot the process of
> detecting which options is button, function, monitoring them depending
> on the types, …. That's as simple as an if () on a string … Also, the
> "wheel" option name is quite fuzzy as well as the 7 it returns. We
> should document names and values.

As explained above, some scanners have "UI elements" like
"function-wheel" that are so vague that you can't give a better
option name. (This was, BTW, one reason why I have a plugin
mechanism for special device features in Eikazo -- I don't feel able
to design a generic frontend that can deal with every option that
one or the other scanner may provide.)

Abel