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

[m. allan noah]

On 1/21/07, Jean-Christophe 'Jice' Cardot <sane at cardot.net> wrote:
> Le dimanche 21 janvier 2007 14:37, m. allan noah a écrit :
> > 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)
>
> yep. In this case my soft will detect as many buttons as there are options
> beginning with "button". As I made the GUI with a 5 buttons limitation, this
> will cause problems.
> Which one of those are real buttons?

maybe 5 or six of them are buttons, but there is no reason for your
software not to
treat some of the others as buttons too- when the 'topedge' sensor goes off, you
could start scanning, saves a button press.

the fujitsu units have a single-digit lcd screen labeled 'function',
the user can set it to
any number from 0-9. in the windows software, it 'combines' with a
button press to
cause scanning in different user-defined modes.

>
> I don't understand very well wy the sensors are not named "sensor-"
> like "sensor-inkremain". For me it would be easier that only buttons are
> beginning with "button-"... (to support the fujistu backend, I would have to
> make my frontend to know what are the real buttons for the fujistsu backend,
> and it sucks ;)

they are not called sensor because your software ignores them :)

> > > > 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.
>
> I think you rather need to name the functionnality rather than copy the label
> on the scanner. "mail" is better than "send a email", "scan & email", "one
> touch email" or I don't which name the marketing will have choosen...
>

i disagree completely. bad UI design to expect the user to interpolate
these values,
when the backend author likely knows exactly what the scanner will say...

allan

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