[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

> the windows software does boolean logic on this value, along with
> the state of the other buttons and sensors, to provide many 'preset'
> scan modes. it might be nice if your code could support that idea.

Agree, i'll implement this once i have user feedback. I may ping you
then for deeper information.

> the duplex switch is the one i consider most problematic, and i have
> considered hiding it, since the backend has a 'source' option to
> control that.

Agree.

About duplex, note that i prefer backend to have a boolean "duplex"
option, similar to printing option. This is the frontend point of view
thru ;)

> i dont have a problem with making button names into well-known
> options, as long as we agree that there are scanners with unlabelled
> buttons, making button-%d your best option.

Agree.

However, buttons with icon should be "translated" to text as much as
possible. I guess think that picture labelled button doesn't change
meaning accross countries.



So, go for some well known options for sensors. How to publish them ?
Which option to publish ? Should you append it to the SANE standard or
use an external document subject to more evolution ?

Regards,
?tienne.

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

I read a bit the fujitsu backend source (sadly, i don't have such fuji
scanners). The sensor handling is exactly what i asked for :D !!

Each sensor is named "button-" and  is not a number but
something like "send", "scan", etc. :) That is PER - FECT :D

I just suggest to expand this behaviour for each backend :

  * Prefix sensor with "button-"
  * Use semantic name
  * "send" for button "send to", "mail", "mail to" or with a
mail icon on the device
  * "scan" for button triggering the scan
  * "duplex" for duplex switch
  * "powersave" once the scanner enter powersave state
  * "adfopen" once the ADF is opened
  * "paperin" once paper is inserted either in sheetfed
scanner or ADF.
  * "auto" for blank button that mean either "scan" or
"cancel" depending on the current stage.
  * other may come, of course

greping the source tree, backends plusteck, hp3900 and pixma use
"button-%d" or similar. Would be nice to have semantic button instead.

Can we publish a document describing such well known sensors ? This is a
tiny incremental evolution of SANE that can make a really good
difference for end user.

Regards,
?tienne.

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

> the button should be called something as close as possible to the
> writing on the scanner, not the front-end authors list of words he
> understands.

I don't mean to impose naming, just propose convention. Is the goal of
SANE just to dump device design or to abstract device ? I guess the
latter since frontend must not have device specific code, see well-known
option. This is why "resolution" option is not named "dpi" on other
backend.

> there is no 'email' button on a fujitsu, there is a 'Send
> to' button.

Just set title to "Send to" for UI and let's use a generic untranslated
name for frontend. If the consensus is to use "sendto" rather than
"email", then go for it. It just needs to be meaningfull and consistent
accross backend.? I don't mean to forbid other sensors.

> then, you dont need to interpret the values, you only need to ask the
> user- what do you want to do when 'Send to button' is pressed?

Users want computer to *just work*, not to popup dialog everytime
someting happen.


SANE should not decide whether frontend have to interpret or not
sensors.

KScannerButton won't interpret and allow fine tweaking of action (even
allowing to edit the shell script executed ; but GNOME will interpret as
much as possible before asking user what to do. That's a matter of
userbase target.

Please consider i propose well known sensors not to have a nice to see
code, but because users want it. GNOME does not target the same userbase
as KDE or XSane. We (at GNOME) target end user that really don't want to
spend their time configuring their computer, and they are numerous.


So please consider providing well known semantic for sensor as well.
Just like we already do for well known option.


Regards,
?tienne.

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

KScannerButtons work like this. See
http://jice.free.fr/KScannerButtons/ .

However, this is completely incompatible with end user (think grand-ma)
who just want the scanner to cancel once she pushed that damn cancel
button, and not one more popup asking what to do (while the scanning is
continuing) ! ;)

Regards,
?tienne.

[sane-devel] Well known sensor

[Julien BLACHE]

"m. allan noah"  wrote:

> understands. there is no 'email' button on a fujitsu, there is a 'Send
> to' button. This is of course complicated by the fact that some
> scanners have localized versions and some only have pictures.

UI nightmare :-)

> then, you dont need to interpret the values, you only need to ask the
> user- what do you want to do when 'Send to button' is pressed?

Exactly.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

[Alessandro Zummo]

On Mon, 17 Mar 2008 20:17:50 +0100
Julien BLACHE  wrote:

> The backend doesn't know, either. Currently the buttons are used
> mostly by custom frontends which do know what's hiding behind the
> buttons.
> 
> There is no standard in SANE, which is a problem, but even worse
> there's nothing standard accross all the hardware.
> 
> It's not a trivial problem to fix, as past discussions have shown.

 I believe in windows it works this way:

 - every driver/backend exports the supported buttons
 - the OS asks the user to bind the button to a specific function

 this way it doesn't matter how the button is called.
 I've seen an epson with "Scan, Mail, PDF" and a Fujitsu
 with "Button 0, Button 1, ..." /

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[sane-devel] Well known sensor

[m. allan noah]

On 3/17/08, ?tienne Bersac  wrote:
> Hi,
>
>  I read a bit the fujitsu backend source (sadly, i don't have such fuji
>  scanners). The sensor handling is exactly what i asked for :D !!
>
>  Each sensor is named "button-" and  is not a number but
>  something like "send", "scan", etc. :) That is PER - FECT :D

i am glad you like it :)

>  I just suggest to expand this behaviour for each backend :
>
>   * Prefix sensor with "button-"
>   * Use semantic name
>   * "send" for button "send to", "mail", "mail to" or with a
> mail icon on the device
>   * "scan" for button triggering the scan
>   * "duplex" for duplex switch
>   * "powersave" once the scanner enter powersave state
>   * "adfopen" once the ADF is opened
>   * "paperin" once paper is inserted either in sheetfed
> scanner or ADF.
>   * "auto" for blank button that mean either "scan" or
> "cancel" depending on the current stage.
>   * other may come, of course
>
>  greping the source tree, backends plusteck, hp3900 and pixma use
>  "button-%d" or similar. Would be nice to have semantic button instead.
>
>  Can we publish a document describing such well known sensors ? This is a
>  tiny incremental evolution of SANE that can make a really good
>  difference for end user.

the fujitsu machines also have a 'function' digit, which ranges from
0-9. the windows software does boolean logic on this value, along with
the state of the other buttons and sensors, to provide many 'preset'
scan modes. it might be nice if your code could support that idea.

the duplex switch is the one i consider most problematic, and i have
considered hiding it, since the backend has a 'source' option to
control that. it is only on older scanners anyway.

i dont have a problem with making button names into well-known
options, as long as we agree that there are scanners with unlabelled
buttons, making button-%d your best option.

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

[sane-devel] Well known sensor

[Julien BLACHE]

?tienne Bersac  wrote:

Hi,

>> This is, or isn't, SANE 2 stuff. You're not going anywhere with that
>> and SANE 1.
>
> I don't understand your sentence. I just mean renaming option in
> backend, change some option type. That is mostly a matter of
> implementation.

And breaking stuff while at it.

> Currently, SANE backend sensor implementation mean : "Something  happen,
> guess what". E.g. plustek backend provide "button 0" to "button 4", both
> integer with value 0. Once a button is pushed, value is 1. How can a
> frontend know what does mean "button 0"=1 ? Can guess "button 0"
> pressed. But what next ??

The backend doesn't know, either. Currently the buttons are used
mostly by custom frontends which do know what's hiding behind the
buttons.

There is no standard in SANE, which is a problem, but even worse
there's nothing standard accross all the hardware.

It's not a trivial problem to fix, as past discussions have shown.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

> This is, or isn't, SANE 2 stuff. You're not going anywhere with that
> and SANE 1.

I don't understand your sentence. I just mean renaming option in
backend, change some option type. That is mostly a matter of
implementation.

If you don't want to extend SANE 1 standard (like e.g. 1.2), just
provide a RFC for backend developer in order to have backend consistent
and sensor usable by frontend, without end user interaction to assign
sensor to action.

Currently, SANE backend sensor implementation mean : "Something  happen,
guess what". E.g. plustek backend provide "button 0" to "button 4", both
integer with value 0. Once a button is pushed, value is 1. How can a
frontend know what does mean "button 0"=1 ? Can guess "button 0"
pressed. But what next ??

We definitely need semantic in sensors.

Regards,
?tienne.

[sane-devel] Well known sensor

[Julien BLACHE]

?tienne Bersac  wrote:

Hi,

> I propose to extend the standard to provide well known hard selected
> options. Here are some exemple :

This is, or isn't, SANE 2 stuff. You're not going anywhere with that
and SANE 1.

JB.

-- 
Julien BLACHE    
  GPG KeyID 0xF5D65169

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

I forgot to talk about sensor type.

Push button must be boolean representing the "pressed" state of the
button.

Wheel button should be either Word, fixed or string. Well known string
value should be good like "color-mode", "grey-mode" for hardware mode
selector.

Please comment.

Regards,
?tienne.
-- 
E Ultre?a !

[sane-devel] Well known sensor

[Étienne Bersac]

Hi,

SANE allow hardware selected option. I call this "sensor" for short. It
can represent push button (like "scan", "cancel", "mail", etc.), wheel
button (ask Allan for details), paper sensor, cover sensor, etc. Some
device have blank button.

Unlike software selected option, frontend *must* understand the meaning
of a sensor. Software selection option can be dumped to user, title and
desc should be enough for the user. But sensor event must be
interpretted by the software.

Currently, backends often use "button %d" or "button-%d" which actually
does not help frontend to handle events.

The backend is aware of the meaning of sensor. It can know what value
mean what action according to either datasheet or device it self.

frontend needs an untranslated and extensible way to know what to do
with a value from a backend without user interaction.

I propose to extend the standard to provide well known hard selected
options. Here are some exemple :

  * "auto" (for e.g. blank button) : If the device is ready, this
mean trigger scan, else it mean cancel, etc.
  * "scan" trigger scan start
  * "cancel" trigger scan cancelation
  * "mail" send output by mail (e.g. as attached image)
  * "print" send output to printer

We might append or prepend "sensor" before the actual name of the option
in order to avoid collision.

Can we please provide such well known sensor spec and implement it in
backends ?

Regards,
?tienne.

[sane-devel] Well known sensor

[m. allan noah]

On Mon, Mar 17, 2008 at 3:17 PM, Julien BLACHE  wrote:
> ?tienne Bersac  wrote:
>
>
> Hi,
>
>  >> This is, or isn't, SANE 2 stuff. You're not going anywhere with that
>  >> and SANE 1.
>  >
>  > I don't understand your sentence. I just mean renaming option in
>  > backend, change some option type. That is mostly a matter of
>  > implementation.
>
>  And breaking stuff while at it.
>
>
>  > Currently, SANE backend sensor implementation mean : "Something  happen,
>  > guess what". E.g. plustek backend provide "button 0" to "button 4", both
>  > integer with value 0. Once a button is pushed, value is 1. How can a
>  > frontend know what does mean "button 0"=1 ? Can guess "button 0"
>  > pressed. But what next ??
>
>  The backend doesn't know, either. Currently the buttons are used
>  mostly by custom frontends which do know what's hiding behind the
>  buttons.
>
>  There is no standard in SANE, which is a problem, but even worse
>  there's nothing standard accross all the hardware.
>
>  It's not a trivial problem to fix, as past discussions have shown.

the button should be called something as close as possible to the
writing on the scanner, not the front-end authors list of words he
understands. there is no 'email' button on a fujitsu, there is a 'Send
to' button. This is of course complicated by the fact that some
scanners have localized versions and some only have pictures.

then, you dont need to interpret the values, you only need to ask the
user- what do you want to do when 'Send to button' is pressed?

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