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

Étienne Bersac bersace03 at laposte.net
Sun Jan 21 21:26:02 CET 2007


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 ?

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

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

> or better, for the backend to provide translations somehow?

Yes. The better solution would be users to translate just by copying
what's on their own translated device instead of asking for another
translation :)

É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/2725aa71/attachment-0001.pgp


More information about the sane-standard mailing list