Fwd: [sane-standard] SANE2 proposal: split button/option handling

[m. allan noah]

On 1/17/07, Étienne Bersac <bersace03 at laposte.net> wrote:
> Hi,
>
> > sorry Étienne, you will get this twice....
>
> Nop.
>
> > it seems strange at first, but it actually makes it possible for a
> > backend to expose new capabilities that were not thought of at the
> > time sane was designed.
>
> I don't want to freeze the available options nor buttons. The option
> handling in SANE is very good and powerful, however, its use is quite
> confusing. In SANE, "everything is option".

funny, i see that as an advantage :)

>
> > > I propose to design two different way to handle devices options and
> > > buttons. I have only a fuzzy idea of how to design it, however, i'm
> > > quite sure that all those "button" options is just confusing and make
> > > developer live harder.
> >
> > how is writing MORE code in the frontend LESS complicated than the
> > current situation?
>
> frontend has to "parse" option name in order to determine if an option
> is about a button. Also, several options stand for one button. I suggest
> to unify this button handling.

ah, yes, now that i read the current sane2 draft, i agree with that
statement. the draft is unusually complex.

>
> SANE 2¹ seems to handle all buttons in three options. No way to know
> button title/name/desc. How to determine that 4th bit of
> scanner-buttons-status is "Scan film" ?
>

yes, i think a better method is to use a single option for each button
or sensor in the device, and use either a new 'type' or a new
'capability' to indicate that something is a button. or, we could do
as the fujitsu and avision backends do, and just string compare the
start of the option name for 'button-'

>
> > the only change i think we need over the current system is the 'poll'
> > capability to be added to the option descriptor, and for the frontend
> > to get the value periodically.
>
> ACK.
>
> >  i dont see any advantage to adding a
> > set of button routines?
>
> That's just a suggestion. I don't have a clear idea of the API. But we
> must add a clearer way for the frontend to know which buttons is for
> what. (But does the backend even know it ?)
>

backend may not know it. some scanners only say 'button1' or 'button2'
pressed, and the backend developer cannot know what the label on the
outside of the button says, esp. when scanners are sold in many
markets, they may not use a text label at all, just a picture.

allan

>      1. http://sane.alioth.debian.org/sane2/0.08/doc014.html#s4.5.14
>
> Étienne.
> --
> Verso l'Alto !
>
>
>


-- 
"The truth is an offense, but not a sin"