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

m. allan noah kitno455 at gmail.com
Sun Jan 21 14:37:02 CET 2007


On 1/21/07, Jean-Christophe 'Jice' Cardot <sane at cardot.net> wrote:
> Le dimanche 21 janvier 2007 00:17, Étienne Bersac a écrit :
> > Hi,
> >
> > > The backend should have a table storing which button is for which
> > > action. This is doable. Some buttons do not have label (e.g. Canon
> > > CanoScan N1220U), then just use "button" label. For other case, that
> > > just suck to let the user attach random action to random button. Also,
> > > if frontend can be aware of button use, it can provide useful default
> > > action to a button.
> >
> > Another proposal is to use "button-<action>" options of type
> > SANE_TYPE_BUTTON to handle one button. The SANE well-known option ref
> > doc document available <action>s and we discuss here to add other
> > actions as needed.
>
> I like this one. Very simple and easy to parse.
> When the buttons have no label like the CanoScan N1220U, I'd use "button-n" (n
> being a sequencial number starting at zero), instead of "button" simply, thus
> allowing the frontend to distinguish the buttons.

this is how the fujitsu backend works. it provides the following buttons:

    opt->name = "button-topedge";
    opt->name = "button-a3";
    opt->name = "button-b4";
    opt->name = "button-a4";
    opt->name = "button-b5";
    opt->name = "button-adfloaded";
    opt->name = "button-omrdf";
    opt->name = "button-adfopen";
    opt->name = "button-powersave";
    opt->name = "button-send";
    opt->name = "button-manualfeed";
    opt->name = "button-scan";
    opt->name = "button-function";
    opt->name = "button-inklow";
    opt->name = "button-doublefeed";
    opt->name = "button-errorcode";
    opt->name = "button-skewangle";
    opt->name = "button-inkremain";
    opt->name = "button-density";
    opt->name = "button-duplex";

some of these are better called 'sensors' than buttons. i would like
to name them differently, but the string compare makes that difficult.
a capability bit might be better. they are not all boolean (ink
remain, etc)

>
> > We might start with the following list :
> >
> >       * scan
> >       * mail
>
> * fax
> * copy
>
> > Other should come as they are known. This is still the same issue : the
> > well-known-option documentation must be very active while SANE standard
> > itself shoul be very frozen :).
> >

the problem here is that you need to use the name printed on the
scanner if there is one. in this case, translation might be a bad
idea.

allan



More information about the sane-standard mailing list