Fwd: SANE2 proposal: split button/option handling

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: 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.
(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?

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

sane-standard mailing list: [hidden email]
Unsubscribe: Send mail with subject "unsubscribe your_password"
             to  [hidden email]

attachment0 (196 bytes) Download Attachment