[sane-devel] scanner buttons

Henning Meier-Geinitz henning@meier-geinitz.de
Fri, 9 Jul 2004 20:49:44 +0200


Hi,

On Fri, Jul 09, 2004 at 11:51:02AM +0200, Rene Rebe wrote:
> As mentioned in the last button thread (from January or so), I use
> normal options. Proposed capabilities have been SANE_CAP_SOFT_DETECT |
> SANE_CAP_HARD_SELECT (| SANE_CAP_ADVANCED). But I think
> SANE_CAP_HARD_SELECT is missleading:
> 
> "The option value can be set by user-intervention (e.g., by flipping a
> switch).  The user-interface should prompt the user to execute the
> appropriate action to set such an option.  This capability is mutually
> exclusive with SANE_CAP_SOFT_SELECT (either one of them can be set,
> but not both simultaneously)."
> 
> The user should not be able to toggle the option in the interface ...

I think that paragraph just means that if the frontend shows such an
option and if the user selects it that "prompt the user..." should
happen. So e.g. xsane could print a text label "`option.title' (enable
on scanner directly)". I think hard_select is the right option to use
for buttons. At least buttons, switches and manual settings like ADFs
are the only use I can think of for this option type.

> So currently I use "SANE_CAP_SOFT_DETECT (|SANE_CAP_ADVANCED)".

I think that means that this is an option whose value can't be set by
the user at all. Maybe an infomation like "20 pages in ADF left" or
even the internal ID of the scanner.

> And as work around for my "when to flush the state to false" for the
> buttons I only re-fetch them from the scanner if sane_control_option
> is called for the first button available.

Ah, I think I understand the flush problem now. The button status of
the scanner is flushed each time you read the button status from the
scanner? If you want to buffer the buttons, why not ask the scanner
for the button status every time a button option is read and only set
the status "button pressed" for every button. Don't set "button not
pressed". The button status is reset to "not pressed" when the
respective option is read.

> Of course the interface details can be easily changed - and I'm open
> for suggestions or interfaace additions to mark to-be-polled options.

SANE_CAP_AUTO_POLL

But I'd really wait for 2.0 for such changes.

Bye,
  Henning