of course, now that i think about it, this idea has the same problem of device ownership/locking. i suppose you could change every backend to lock open devices (plustek does this already?), and every front-end would have to send/accept signals based on lock ownership? sounds ugly...
allan On 3/20/07, m. allan noah <kitno...@gmail.com> wrote: > On 3/20/07, ?tienne Bersac <bersac...@laposte.net> wrote: > > Hi allan, > > > > > it would be nice if some of the linux gnome devels would engage in > > > SANE discussions on the SANE lists. they might learn something about > > > the hardware they are trying to support :) button handling comes up > > > here quite a bit, you should search the archives of the sane-devel and > > > sane-standard mailing lists. > > > > You know i'm contributing to this list. The discussion on Gnome derived > > to SANE and thus, land here. Don't threat a Gnome devels complot ;P > > just trying to make sure you guys were paying attention :) > > > > > > 1. you need a piece of code that understands the button-reading > > > protocol for every scanner that sane supports. you will end up > > > replicating a fair bit of code that is already (hopefully) in > > > sane-backends, esp. for devices that require a bit of initialization > > > before they can communicate. > > > > ACK. I really don't want to have "buttons monitor backends" and > > "acquisition backends". That's crazy to maintain. The HAL add-on will > > use SANE and provide two dbus method (e.g. Reclaim and Release) in order > > to transmit device ownership. > > > > > 2. what happens when the user fires up scanimage command line tool > > > without pressing any buttons? how do we deal with the contention for > > > the device? > > > > Don't use HAL :). > > > > so now every linux distro that enables HAL support in SANE, locks > their users out of the most commonly used frontend, just to get button > support? > > i would rather see a more general, non-linux specific method of > handling buttons. how about a daemon that runs, gets the sane device > list in the normal way, and then monitors each of the found devices > for button presses as regular sane options. > > when a press is found, and there is a configured event to run, it > sane_close() that device and fork/exec another frontend, passing it > the device name as an arg. when the child exits, the daemon could > regrab? > > on linux, sane_get_devices and other such functions might have the > ability to use a more advanced device finding capability? > > allan > > -- > "The truth is an offense, but not a sin" > -- "The truth is an offense, but not a sin"