Quantcast

SANE2 proposal: split button/option handling

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SANE2 proposal: split button/option handling

Étienne Bersac-3
Hi,

There is something very strange in SANE 1 (and SANE 2 draft): all is
option. I think that's not easy for frontend to handle devices
(especially buttons) with this design. It's very confusing.

I propose to design three 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.

Device options handling keep similar as current implemententation.

Device buttons handling might be like the following braindump :

      * Define a SANE_Button_Descriptor struct which contains name,
        title and desc of the button.
      * Define a sane_device_button_lock (device, button) and
        sane_device_button_unlock (device, button) functions which
        behave like sane_open () and sane_close ().
      * Define a sane_device_button_get_status (device, button) which
        allow to monitor button status.

Please comment.

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: SANE2 proposal: split button/option handling

m. allan noah-3
sorry Étienne, you will get this twice....

On 1/17/07, Étienne Bersac <[hidden email]> wrote:
> Hi,
>
> There is something very strange in SANE 1 (and SANE 2 draft): all is
> option. I think that's not easy for frontend to handle devices
> (especially buttons) with this design. It's very confusing.

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 propose to design three 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?

>
> Device options handling keep similar as current implemententation.
>
> Device buttons handling might be like the following braindump :
>
>       * Define a SANE_Button_Descriptor struct which contains name,
>         title and desc of the button.

very much like the name/title/desc of an option?

>       * Define a sane_device_button_lock (device, button) and
>         sane_device_button_unlock (device, button) functions which
>         behave like sane_open () and sane_close ().

why not just use sane_open and close? you cannot have two different
running copies of the backend talking to the scanner at the same
moment, so having an independent lock function gives no advantage.

>       * Define a sane_device_button_get_status (device, button) which
>         allow to monitor button status.
>

just like like sane_control_option?

see how similar it is?

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. i dont see any advantage to adding a
set of button routines?

allan

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


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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: SANE2 proposal: split button/option handling

Étienne Bersac-3
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".

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

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" ?


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

     1. http://sane.alioth.debian.org/sane2/0.08/doc014.html#s4.5.14

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: SANE2 proposal: split button/option handling

m. allan noah-3
On 1/17/07, Étienne Bersac <[hidden email]> 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"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
Hi,

> we could do
> as the fujitsu and avision backends do, and just string compare the
> start of the option name for 'button-'

Agree.

I suggest to add a "poll-button-state" option to sane_open (), and then
have just one "button-*" option of type SANE_TYPE_BUTTON per button. The
frontend then just read the value of this option to know the state of
the button. If the backend does not poll the button state, then the
button is never pressed.

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

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.

Regards,
Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
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.

We might start with the following list :

      * scan
      * mail

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

Please comments,
Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Jean-Christophe 'Jice' Cardot
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.

> 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 :).
>
> Please comments,
> Étienne.

--
Jean-Christophe "Jicé" Cardot - http://lea-linux.org

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

m. allan noah-3
On 1/21/07, Jean-Christophe 'Jice' Cardot <[hidden email]> 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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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 <[hidden email]> 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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

m. allan noah-3
On 1/21/07, Jean-Christophe 'Jice' Cardot <[hidden email]> wrote:

> Le dimanche 21 janvier 2007 14:37, m. allan noah a écrit :
> > On 1/21/07, Jean-Christophe 'Jice' Cardot <[hidden email]> 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"

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
Hi,

That would be nice to have "function-*", "button-*" and "sensor-*"
SANE_TYPE_BUTTON option. That will help frontend provide fine GUI
adapted to the different event software.

Also, about label, why not use title to provide the real button label ?

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

m. allan noah-3
On 1/21/07, Étienne Bersac <[hidden email]> wrote:
> Hi,
>
> That would be nice to have "function-*", "button-*" and "sensor-*"
> SANE_TYPE_BUTTON option. That will help frontend provide fine GUI
> adapted to the different event software.

i agree, but the description of TYPE_BUTTON indicates that it is for
frontend to signal backend, not the other way. i suppose some combination
of capabilities could be used for this?

>
> Also, about label, why not use title to provide the real button label ?
>

ok, then what shall you use as the name? remember that there are
plenty of front-ends that are not GUI, and might only show the name,
not the title and desc...

allan

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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
Hi,

> i agree, but the description of TYPE_BUTTON indicates that it is for
> frontend to signal backend, not the other way.

And nobody use such buttons. I find this feature very strange. It's
confusing about device buttons. If we want to keep this features (use
option as call), we should use SANE_TYPE_FUNCTION or something less
confusing.

This is another question : should we use "button-", "sensor-",
"function-" or TYPE_BUTTON, TYPE_SENSOR, TYPE_FUNCTION ? I vote for the
later.

> then what shall you use as the name? remember that there are
> plenty of front-ends that are not GUI, and might only show the name,
> not the title and desc...

An "id" (i.e. lowercase + number + dashes). That's easy to use in
cmdline. Do you prefer typeing "adf" or "Automatic Document Feeder -
Front" ? :)

Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

m. allan noah-3
On 1/21/07, Étienne Bersac <[hidden email]> wrote:

> Hi,
>
> > i agree, but the description of TYPE_BUTTON indicates that it is for
> > frontend to signal backend, not the other way.
>
> And nobody use such buttons. I find this feature very strange. It's
> confusing about device buttons. If we want to keep this features (use
> option as call), we should use SANE_TYPE_FUNCTION or something less
> confusing.
>
> This is another question : should we use "button-", "sensor-",
> "function-" or TYPE_BUTTON, TYPE_SENSOR, TYPE_FUNCTION ? I vote for the
> later.

we already have enough types. we can hold ints, strings, bools,
decimals, and this unused 'button'. some scanners will provide ints or
floats in response to a sensor or button, others will return strings.
trust me, none of us understands all the high-level options that might
be provided by a scanner, so we can only give the low level
'building-blocks' that a backend author may need, and some guidelines
to suggest extensions to the api.

> > then what shall you use as the name? remember that there are
> > plenty of front-ends that are not GUI, and might only show the name,
> > not the title and desc...
>
> An "id" (i.e. lowercase + number + dashes). That's easy to use in
> cmdline. Do you prefer typeing "adf" or "Automatic Document Feeder -
> Front" ? :)

ok, so the id needs to match what is on the outside of the scanner.
dont rely on the title.

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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
Hi,

> we already have enough types. we can hold ints, strings, bools,
> decimals, and this unused 'button'. some scanners will provide ints or
> floats in response to a sensor or button, others will return strings.
> trust me, none of us understands all the high-level options that might
> be provided by a scanner,

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.

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.

> so we can only give the low level
> 'building-blocks' that a backend author may need, and some guidelines
> to suggest extensions to the api.

I don't understand what is "building-blocks" option.

> > An "id" (i.e. lowercase + number + dashes). That's easy to use in
> > cmdline. Do you prefer typeing "adf" or "Automatic Document Feeder -
> > Front" ? :)
>
> ok, so the id needs to match what is on the outside of the scanner.
> dont rely on the title.

Hmm. the idea is that id should uniform buttons whatever is outside the
scanner. For example, on HP all-in-one device, the buttons label are
translated by changing a big piece of plastic where all labels are
printed (with holes to let buttons stick out). Uniformize all for
frontends all buttons which says more or less "scan", "mail", "fax",
"copyp", … and store all the label variation in title sounds good.

Please comment,
Étienne.
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

m. allan noah-3
On 1/21/07, Étienne Bersac <[hidden email]> wrote:

> Hi,
>
> > we already have enough types. we can hold ints, strings, bools,
> > decimals, and this unused 'button'. some scanners will provide ints or
> > floats in response to a sensor or button, others will return strings.
> > trust me, none of us understands all the high-level options that might
> > be provided by a scanner,
>
> 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.

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

>
> > so we can only give the low level
> > 'building-blocks' that a backend author may need, and some guidelines
> > to suggest extensions to the api.
>
> I don't understand what is "building-blocks" option.

sorry, not another option, i was trying to say that i think we can do what you
need with just well-named options, and the minimum of changes to the various
types and structs in sane.

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'}

> Hmm. the idea is that id should uniform buttons whatever is outside the
> scanner. For example, on HP all-in-one device, the buttons label are
> translated by changing a big piece of plastic where all labels are
> printed (with holes to let buttons stick out). Uniformize all for
> frontends all buttons which says more or less "scan", "mail", "fax",
> "copyp", … and store all the label variation in title sounds good.

or better, for the backend to provide translations somehow?

allan

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling (was: SANE2 proposal: split button/option)

Étienne Bersac-3
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 !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling

abel deuring
Étienne Bersac wrote:

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

No. Allan "only" gave an example of a "UI element" _on the scanner_
that is not a button, but an switch/wheel with 6 or 8 or 9
positions. The setting of this switch is represented as an integer
when the backend asks the scanner for some status information, and
the backend passes this information up to the frontend as a
read-only option of type int; perhaps with a constraint.

A similar "UI element" is, BTW, available on new Fujitsu scanners.
Some have a simple one-digit 7-segment display for the numbers 0 to
9. The display value can be set by two buttons on the scanner, but
these buttons are not accessible by the backend (or any other
driver) -- the scanner tell the computer _only_ the displayed value.

A scan program (or frontend in Sane terminology) can for example
provide a configuration dialog which allows the user to assign the
action "send scan to email address XYZ" to the value 1; "COPY" or
"print scanned image" to the value 2, "save to file" to the value 3,
"send scan to email address ABC" to value 4 etc. The user must
perhaps "improve" the UI by using Scotch tape to glue a label onto
the scanner with explanations what each setting means.

SANE_TYPE_BUTTON is _completely_ different from the things we have
discussed so far. The name is perhaps misleading, but it means an
option that may be represented in the GUI of a frontend by a
clickable button. Several backends provide such options, a quick
grep through the source code of the backends shows that they are
used for things like "swicth lamp on/off", "calbrate now" etc.

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

Cleanup of Sane1 options will not work. Why should anyone put much
work into cleanup of old code, when you can expect that work on new
code will start quite soon?

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

As explained above, some scanners have "UI elements" like
"function-wheel" that are so vague that you can't give a better
option name. (This was, BTW, one reason why I have a plugin
mechanism for special device features in Eikazo -- I don't feel able
to design a generic frontend that can deal with every option that
one or the other scanner may provide.)

Abel

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling

Étienne Bersac-3
Hi,

> SANE_TYPE_BUTTON is _completely_ different from the things we have
> discussed so far. The name is perhaps misleading, but it means an
> option that may be represented in the GUI of a frontend by a
> clickable button. Several backends provide such options, a quick
> grep through the source code of the backends shows that they are
> used for things like "swicth lamp on/off", "calbrate now" etc.

Ok, thanks, i misunderstood this. Off-topic, can you explain what
actually is calibration, and how often is that needed ?

> Cleanup of Sane1 options will not work. Why should anyone put much
> work into cleanup of old code, when you can expect that work on new
> code will start quite soon?

Whatever version you call it, (1.1 or 2.0), SANE needs a clean up in
option names and value variation in backends. That's doable in SANE 1, i
mean keeping the current SANE API (excluding Well-Known-Option by using
an external Well-Known options reference), keeping binary compatibility.

> As explained above, some scanners have "UI elements" like
> "function-wheel" that are so vague that you can't give a better
> option name.

Ok.

Is there an easy way to know if an option is for frontend itself or for
user ? For example, the plustek backend show 5 "button" option for my
CanoScan N1220U, and xsane shows an unsensitive checkbox for this
button, in a "buttons" frame. That's useless and even annoying for
end-users. Why is that option shown ? Is there a way for backend to
tell : this option is not for user. I think about SANE_CAP_HARD_SELECT.
Am i wrong ?

Thanks,
Étienne
--
Verso l'Alto !

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Button handling

m. allan noah-3
On 1/21/07, Étienne Bersac <[hidden email]> wrote:

> Hi,
>
> > SANE_TYPE_BUTTON is _completely_ different from the things we have
> > discussed so far. The name is perhaps misleading, but it means an
> > option that may be represented in the GUI of a frontend by a
> > clickable button. Several backends provide such options, a quick
> > grep through the source code of the backends shows that they are
> > used for things like "swicth lamp on/off", "calbrate now" etc.
>
> Ok, thanks, i misunderstood this. Off-topic, can you explain what
> actually is calibration, and how often is that needed ?

you must be a front-end developer :) there is a natural variance in strength
of signal from each cell in a read-head, variation in brightness of
lamp, etc. most scanners
have a white or black (or both) stripe inside, which the head reads to
determine offsets
required to correct for many such issues. some scanners ($$$) do this
automatically, others require this from backend.

>
> > Cleanup of Sane1 options will not work. Why should anyone put much
> > work into cleanup of old code, when you can expect that work on new
> > code will start quite soon?
>
> Whatever version you call it, (1.1 or 2.0), SANE needs a clean up in
> option names and value variation in backends. That's doable in SANE 1, i
> mean keeping the current SANE API (excluding Well-Known-Option by using
> an external Well-Known options reference), keeping binary compatibility.
>

sure- its doable, but will any developer bother if he is thinking
about sane2? perhaps- if a minimum subset of this list is required for
sane2 compliance...

> > As explained above, some scanners have "UI elements" like
> > "function-wheel" that are so vague that you can't give a better
> > option name.
>
> Ok.
>
> Is there an easy way to know if an option is for frontend itself or for
> user ? For example, the plustek backend show 5 "button" option for my
> CanoScan N1220U, and xsane shows an unsensitive checkbox for this
> button, in a "buttons" frame. That's useless and even annoying for
> end-users. Why is that option shown ? Is there a way for backend to
> tell : this option is not for user. I think about SANE_CAP_HARD_SELECT.
> Am i wrong ?

xsane does not handle reading button presses from backend AFAIK.

allan

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

--
sane-standard mailing list: [hidden email]
http://lists.alioth.debian.org/mailman/listinfo/sane-standard
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]
12
Loading...