Hi,
On Fri, Jul 09, 2004 at 09:21:01PM +0200, Rene Rebe wrote:
> Regarding SANE 2: Do you have any idea if coding on it will ever start
> ,-)? I mean, how long are we discussing proposals already?
We can only start coding when the standard is finished (or at least
the "critical points" are finish
HI,
On: Fri, 9 Jul 2004 21:05:13 +0200,
Henning Meier-Geinitz wrote:
> Don't forget that option values may be bigger than a view bytes. E.g.=
> gamma tables. And SANE also works over the net and constant polling o=
f
> all options seems rather useless for me. I think it's not that
> complic
Hi,
On Fri, Jul 09, 2004 at 10:09:45AM -0400, m. allan noah wrote:
> ok, here's a crazy idea- why not just reload the entire option array every
> few seconds? the backend then gets to decide what order to reload them in
> (i.e. load the 'mode' switch first, then change all the mode params, then
Hi,
On Fri, Jul 09, 2004 at 09:45:03AM -0400, m. allan noah wrote:
> > Hm - maybe callback stuff are too much changes for 1.x - maybe we
> > should finally start working on SANE 2?
>
> can we do callbacks via options? thinking about a gui front-end:
>
> what about an 'led' that is red while the
Hi,
On Fri, Jul 09, 2004 at 03:35:47PM +0200, Rene Rebe wrote:
> > I also think we need some callback stuff for warmup notification.
>
> Hm - maybe callback stuff are too much changes for 1.x - maybe we
> should finally start working on SANE 2?
There is no way to add callbacks to 1.0.
> In my l
Hi,
On Fri, Jul 09, 2004 at 03:20:12PM +0200, Gerhard Jaeger wrote:
> > i think we need a polling capability, though that would mean changes to
> > front-ends
>
> Yes I also think so! We should add this to the current stuff!
I don't think we should do that in SANE 1.0. While that works for o
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 missleadi
Hi,
On Fri, Jul 09, 2004 at 01:20:14AM +0200, Rene Rebe wrote:
> When the state is read by the application, it should be in some way
> reset. Any idea how this fits into the proposed ideas - especially if
> we have single options?
Once the option has been read by the frontend, reset the value to
> ok, here's a crazy idea- why not just reload the entire option array every
> few seconds? the backend then gets to decide what order to reload them in
> (i.e. load the 'mode' switch first, then change all the mode params, then
> load the 'scan' button press).
>
> is this nuts?
>
> allan
>
> ok, here's a crazy idea- why not just reload the entire option array every
> few seconds? the backend then gets to decide what order to reload them in
> (i.e. load the 'mode' switch first, then change all the mode params, then
> load the 'scan' button press).
>
> is this nuts?
>
> allan
>
W
On Friday 09 July 2004 16:09, m. allan noah wrote:
---8<--
> ok, here's a crazy idea- why not just reload the entire option array every
> few seconds?
then we get some kind of "Flash" application, which does nothing than simply
reloading/repaint
Hi,
On: Fri, 9 Jul 2004 09:45:03 -0400 (EDT),
"m. allan noah" wrote:
> > In my last mail I already wrote that the HP 74xx have buttons to
> > change the scan mode and copy count - this are also use cases where=
> > the "option changed" callbacks come handy.
> > =
> =
> can you think of a
Hi,
On: Fri, 9 Jul 2004 15:20:12 +0200,
Gerhard Jaeger wrote:
> > i think we need a polling capability, though that would mean change=
s to
> > front-ends
> =
> Yes I also think so! We should add this to the current stuff!
> I also think we need some callback stuff for warmup notificati
Hi,
On: Fri, 9 Jul 2004 09:12:19 -0400 (EDT),
"m. allan noah" wrote:
> > The user should not be able to toggle the option in the interface .=
..
> =
> do any other backends currently use hard_select? if not, perhaps that=
=
> description should be updated slightly?
A quick grep only revi
On Friday 09 July 2004 15:12, m. allan noah wrote:
---8<---
> > The user should not be able to toggle the option in the interface ...
>
> do any other backends currently use hard_select? if not, perhaps that
> description should be updated slightly?
On Fri, 9 Jul 2004, David Stevenson wrote:
> > ok, here's a crazy idea- why not just reload the entire option array every
> > few seconds? the backend then gets to decide what order to reload them in
> > (i.e. load the 'mode' switch first, then change all the mode params, then
> > load the 'sca
Hi,
On: Fri, 9 Jul 2004 10:09:31 +0200,
Gerhard Jaeger wrote:
> Hi Rene,
> =
> I'm somewhat curious on your implementation ;-) How will you solve th=
is?
> Are you using some kind of background process or thread to update
> peridodically the status? What is the callback, or the corresponding
On Fri, 9 Jul 2004, Gerhard Jaeger wrote:
> On Friday 09 July 2004 16:09, m. allan noah wrote:
> ---8<--
> > ok, here's a crazy idea- why not just reload the entire option array every
> > few seconds?
>
> then we get some kind of "Flash" applic
> > > In my last mail I already wrote that the HP 74xx have buttons to
> > > change the scan mode and copy count - this are also use cases where
> > > the "option changed" callbacks come handy.
> > >
> >
> > can you think of a case where a call-back is required? (i want to avoid
> > them, if pos
Hi Rene,
I'm somewhat curious on your implementation ;-) How will you solve this?
Are you using some kind of background process or thread to update
peridodically the status? What is the callback, or the corresponding
sane_ function, that a frontend can use?
Ciao,
Gerhard
On Friday 09 July 2004
> > > i think we need a polling capability, though that would mean changes to
> > > front-ends
> >
> > Yes I also think so! We should add this to the current stuff!
> > I also think we need some callback stuff for warmup notification.
>
> Hm - maybe callback stuff are too much changes for 1.x
> > I'm somewhat curious on your implementation ;-) How will you solve this?
> > Are you using some kind of background process or thread to update
> > peridodically the status? What is the callback, or the corresponding
> > sane_ function, that a frontend can use?
>
> As mentioned in the last butt
Hi,
I'm currently implementing button support for the Avision backend
(because users asks for it ...). I run into a tiny issue:
When the state is read by the application, it should be in some way
reset. Any idea how this fits into the proposed ideas - especially if
we have single options?
On: Sa
Hi,
On Tue, Feb 10, 2004 at 05:10:31PM -0500, m. allan noah wrote:
> 1. we would like a backend to be able to signal a frontend when a button
> or sensor is tripped.
>
> 2. if the backend is polled, it needs a way to request the polling
> interval.
Why? Shouldn't it be up to the frontend to de
ok, just to recap what i am seeing here.
1. we would like a backend to be able to signal a frontend when a button
or sensor is tripped.
2. if the backend is polled, it needs a way to request the polling
interval.
3. the stati are generally not accessed via a separate command for each
sensor,
>You ask the wrong question. The people do not close their frontend and this
>would make it impossible for the others to scan when the device is locked.
Man, Oliver, you must have a lot of very cranky and forgetful people where
you work; this seems to be a serious problem for you!
It seems to
Henning Meier-Geinitz schrieb:
> Depends on what is more important for you. There is not only the
> privacy problem, you don't even know if the scanner you want to use is
> the same, after you have closed the device file.
>
> This is especially a problem with hot-pluggable devices like USB. If
>
Matto Marjanovic schrieb:
> I don't see how not locking the device continuously from sane_open() to
> sane_close() has any advantage, aside from not requiring users to quit
> xsane when they are done with a job.
You ask the wrong question. The people do not close their frontend and this
would m
Hi,
On Wed, Sep 11, 2002 at 01:25:43PM -0400, Matto Marjanovic wrote:
> Furthermore (last thoughts before I go to work)...
Last thought before I go to bed (not really) :-)
> The ADF problem could be fixed with the addition of a single, new, kind-of-
> -well-known-option. It would be a boolean
Hi,
On Wed, Sep 11, 2002 at 12:16:13PM -0400, Matto Marjanovic wrote:
> Couldn't this be implemented as an ADF-like feature of a backend?
Probably yes. That's a good idea, at least until we have a better
solution.
> A backend for a scanner with a handy button could have a "multiple pages
> via
Matto Marjanovic, Mittwoch, 11. September 2002 18:16:
> >I've lost a little bit track of what you've already discussed, but as a
> > user, what I would think is a nice feature is when I can take a bunch of
> > papers, sit beside the scanner and only need to press the scanner button
> > each tim
Oliver Rauch, Mittwoch, 11. September 2002 15:21:
> > Don't know, whether I understand this correctly, but isn't this a huge
> > security/privacy problem?
> > Let's say, user A starts his frontend, stands up, walks to the scanner
> > and puts some confidential or at least private document on the sc
I've lost a little bit track of what you've already discussed, but as a user,
what I would think is a nice feature is when I can take a bunch of papers,
sit beside the scanner and only need to press the scanner button each time,
without grabbing mouse, clicking here and there... Last time I trie
mh schrieb:
>
> Oliver Rauch, Mittwoch, 11. September 2002 12:55:
> > Henning Meier-Geinitz schrieb:
> > On my work I think it is normal that 5 people have the frontend(xsane)
> > opened at the same time, all use the same scanner.
> >
> > With network scanning it really would be bad if one opens a
Hi,
On Wed, Sep 11, 2002 at 12:55:07PM +0200, Oliver Rauch wrote:
> That is not the way a backend should be implemented.
> The backend should store all backend options until sane_start is called.
> When sane_start is called it should transmit all values to the scanner.
>
> This way several fronte
Oliver Rauch, Mittwoch, 11. September 2002 12:55:
> Henning Meier-Geinitz schrieb:
> On my work I think it is normal that 5 people have the frontend(xsane)
> opened at the same time, all use the same scanner.
>
> With network scanning it really would be bad if one opens a frontend
> and keeps it ru
> has an ADF, we're all set (assuming ADF's are handled properly, which they
> aren't quite).
...
>The user still has to initiate the whole process ("start ADF scan") from
> the frontend, but then she slides her chair over to the scanner for the
> duration of her document.
Furthermore (last
Henning Meier-Geinitz schrieb:
>
> Hi,
>
> On Sat, Sep 07, 2002 at 12:27:52AM +0200, Oliver Rauch wrote:
> > The button protocoll should not be implemented this way.
> > The button protocoll has to be network safe. Imagine what happens
> > when 10 frontends poll the buttons at the same time and s
>I don't know, whether you've read my first posting, but the only problem is,
>that there's no way for a frontend to detect whether a button has been
>pressed. What Norman Urs Baier requests is a job for the *frontend* and not
>for the backend :-)
...But, my little epiphany was that if the
Hi,
On Sat, Sep 07, 2002 at 12:27:52AM +0200, Oliver Rauch wrote:
> The button protocoll should not be implemented this way.
> The button protocoll has to be network safe. Imagine what happens
> when 10 frontends poll the buttons at the same time and someone
> does press a button, then up to 10 di
>I've lost a little bit track of what you've already discussed, but as a user,
>what I would think is a nice feature is when I can take a bunch of papers,
>sit beside the scanner and only need to press the scanner button each time,
>without grabbing mouse, clicking here and there... Last tim
>This way several frontends can open the same device and the options are
>set independant.
>
>On my work I think it is normal that 5 people have the frontend(xsane)
>opened at the same time, all use the same scanner.
I don't see how not locking the device continuously from sane_open() to
san
Henning Meier-Geinitz, Freitag, 6. September 2002 21:11:
...
> What should the frontend do when pressing a button? Ask for parameters
> or immediately start the action with default/selected parameters?
This should be completely up to the frontend.
> > Or is there a better/an easier way to make t
Oliver Rauch, Samstag, 7. September 2002 00:27:
...
> Yes.
> The button protocoll should not be implemented this way.
> The button protocoll has to be network safe. Imagine what happens
> when 10 frontends poll the buttons at the same time and someone
> does press a button, then up to 10 different
Henning Meier-Geinitz schrieb:
>
> Hi,
>
> On Thu, Sep 05, 2002 at 02:27:33PM +0200, mh wrote:
> > would it be possible, to add an option called "button-state" to saneopts.h ?
> > "button-state" is an option of SANE_TYPE_INT with SANE_UNIT_NONE and
> > SANE_CONSTRAINT_NONE and capability SANE_CAP
Hi,
On Thu, Sep 05, 2002 at 02:27:33PM +0200, mh wrote:
> would it be possible, to add an option called "button-state" to saneopts.h ?
> "button-state" is an option of SANE_TYPE_INT with SANE_UNIT_NONE and
> SANE_CONSTRAINT_NONE and capability SANE_CAP_SOFT_DETECT (i.e. a read-only
> option).
On Sat, 7 Sep 2002, Oliver Rauch wrote:
> Yes.
> The button protocoll should not be implemented this way.
> The button protocoll has to be network safe. Imagine what happens
> when 10 frontends poll the buttons at the same time and someone
> does press a button, then up to 10 different people do s
Hi,
would it be possible, to add an option called "button-state" to saneopts.h ?
"button-state" is an option of SANE_TYPE_INT with SANE_UNIT_NONE and
SANE_CONSTRAINT_NONE and capability SANE_CAP_SOFT_DETECT (i.e. a read-only
option).
If a frontend detects such an option, it can use a timer to q
48 matches
Mail list logo
