> you could have a flag to a front-end that told it to load the backend, but > instead of scan, constantly check the option descriptor for a button's > status. the front-end could print this, or even take a series of command > line switches that tell it what to do in case of a particular event. but > in all cases, this front-end would have to disconnect from the scanner, so > that the second front-end could load the backend and connect. but, it > would have to still run, so that it could re-connect and continue > monitoring. unless, you wanted to re-start it from your script. > > but you definately dont want backends printing. > > allan >
Is there a problem with restarting it from a script? That seems a natural way to me to separate mechanism from policy and I can imagine a lot of nice uses of what I described. I had assumed that when you pushed a button on a usb scanner, it send a message over the usb that the backend, if it was listening, would get. The way you describe it, the scanner sets a flag internally, meaning something like "button 1 pushed", and the flag stays in that state until the backend asks for its button status, then tells it to reset the status back to "button 1 unpushed". Is that correct? Assuming I've got it, then I think what you described is the way to go. Have the front-end disconnect and exit, printing out a message as to which button was pressed. The script could then invoke scanimage again to scan an image and print the result (if the script author wants to interpret the pressed button that way). You seem to be worried about what would happen if the user pressed a button twice, and the second button press was missed because the controlling script had exited the first front-end invocation and began another to scan. I take it the second button press would be either be dropped, or you wouldn't be able to process it until after the first scan finished, which would mean you couldn't use one of the buttons as a "cancel" button to cancel the scan in progress. If not being able to implement a cancel button bothers you, then how about this? Have another front-end flag that lets you name a file you want button events written to that occur during a scan. Then you could implement the cancel button by specifying a fifo for the file argument, and having a background process read lines from the file, interpret them, and kill the scan in progress in the event of a cancel button push. That's very straight forward in bash. Even without the ability to implement a cancel button, I would love to be able to map scanner buttons to mean things like "scan low res, gray, and write to a spool directory", "scan high res, color, to a spool directory" and "print the next scan". That's assuming I have 3 buttons to work with, of course. So if I want to do a low res scan and have it printed, I hit button 3, wait a second, then hit button 1. If I didn't want it printed, I'd just his button 1 or 2. Hmmm. Would it be possible to push-and-hold button 1, then push-and-release button2, and then release button 1, and have the backend tell the difference from push-and-release 1 followed by push-and-release 2? What exactly generates an event (usb message sent device-to-host) in the case of button presses and releases? Does anyone know? Chris Marshall __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
