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

[Jean-Christophe 'Jice' Cardot]

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?

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 ;)

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

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

> allan

-- 
Jean-Christophe "Jicé" Cardot - http://lea-linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/sane-standard/attachments/20070121/1332b919/attachment.pgp