Fwd: [sane-standard] SANE2 proposal: split button/option handling

[Jean-Christophe 'Jice' Cardot]

Le 17 janvier 2007, Étienne Bersac <bersace03 at laposte.net> a écrit :
> 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.

Hi all

I'm currently developping a frontend (actually a daemon + a GUI) to handle the 
buttons with SANE.
http://cardot.net/KScannerButtons
(the to be published version 0.9.6 is localised in fr/es/de/cs/pt_BR and has 
been tested with 3 backends: avision, hp3900 & plustek, but a lots of 
backends have the word "button" in their source code... - the current version 
supports only avision. If you want to test the latest version, I'll send the 
daemon source to anyone requesting it)

Well it's a nightmare to support all the backends, because no standard exist.
(but the fact that a button is an option is not a problem for me - I'm parsing 
the option name. I saw that the option type SANE_TYPE_BUTTON exists, but is 
it really used for buttons?)

I'd like that SANE 2 has such a standard, but also that current SANE 1 
backends converge to only one way to handle buttons. The avision backend has 
a very good handling of buttons.

In SANE 1 could we standardize the option names & types? "button n" like in 
avision seems a good way to do it, and may be usoing SANE_TYPE_BUTTON (?).

Also the purpose of the button, like SCAN, MAIL, FAX, COPY... could maybe be 
given in the option description?

I'm waiting for your suggestions.

Also, one a few people have decided on a good way to do it, how will it be 
possible to push it to the developpers?

Regards,
-- 
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/20070120/8568f371/attachment.pgp