[Kde-graphics-devel] Re: Using libksane from a non-graphical application

[Kåre Särs]

On Wednesday 27 April 2011 12:27:25 Ben Martin wrote:
> On Wed, 2011-04-27 at 10:09 +0300, Kåre Särs wrote:
> > On Tuesday 26 April 2011 13:26:25 Ben Martin wrote:
> > > Hi,
> > >   I decided to allow libferris to mount scanners at long last. The
> > > basics of this exposure is to configure sane and grab an image to jpg or
> > > png. The code in skanlite does very similar things, but as a filesystem
> > > I don't create any graphical interface. 
> > > 
> > >   It turns out that things work well from the console, though the calls
> > > to KMessageBox::sorry() in KSaneWidgetPrivate::oneFinalScanDone() are
> > > quite deadly as the dialog is not shown and the whole thing seems to
> > > hang there. A visit to gdb shows that the dialog is up and not shown in
> > > the backtrace.
> > > 
> > >   Inside imageReady() I call scanCancel() to try to avoid these
> > > KMessageBoxes but it seems I get two scanDone() signals anyway and the
> > > second one complains that the ADF is out of ammo and thus the
> > > KMessageBox is attempted by libksane.
> > 
> > I guess it would not bee to much of a problem to disable those message boxes.
> 
> I have them disabled locally. I'm not sure what the desired KDE way for
> a more standing fix is. My first thought was the make them generated in
> a virtual method in ksane, or maybe as a callback which you can set to
> override.
> 
> The other idea might be to have ksane check if the qapplication instance
> is graphical or not... or just have a setShowErrorsOnConsole( bool )
> maybe?
> 
> > 
> > I have a hunch that you will need an X server running to be able to create a 
> > QWidget... 
> 
> This seemed to be one of the downsides, that and requiring the linking
> of GUI code to get at the scanner. But its probably better to try to
> refactor ksane at some stage than write my own sane wrapper from
> scratch.
> 
> > 
> > > 
> > >   About the only other thing I see that would be handy is a 
> > > QList< QString > getDeviceNames() const;
> > > sort of method to enumerate the scanners. This assumes that there is any
> > > interest in allowing non graphical clients to pick at libksane. Other
> > > than that libksane allows fairly straightforward scanning from the
> > > console. :)
> > 
> > "QList< QString > getDeviceNames() const;" is actually a feature that I have 
> > had in the plans for some time, but I have not had enough of an itch to do it 
> > (nobody using it). It should not be a big problem to implement.
> > 
> > The proper way to it would be to have a "void initGetDeviceList() const;" that 
> > initiates the thread and a signal that returns the device list. This because 
> > the getting of the list can take several seconds. Then a convenience function 
> > that sits and waits for the signal to be returned.
> > 
> > I'll add an entry to the feature plan before the soft freeze and we can check 
> > what it needs to disable the dialogs and add the getDeviceNames().
> 
> Well, I had hacked together a sync method as above. The patch uses the
> async init() and signal that is the much nicer design. So now half the
> things are done :)
> 
> Though you'll want to remove my commenting out the kmessagebox lines in
> the patch.
> 

Thanks, I'll apply the patch as soon as I get a chance :)


I think forwarding the error to the application in stead of showing them as dialog 
box would be better. I'll add a signal that the application can connect to and if the 
signal is connected the dialog will not be shown. That should not break the API or ABI


> > 
> > > 
> > > (oh, I'm not on list, please CC relies if any).
> > 
> > Sure, I'm happy if somebody wants to use/improve libksane :)
> 
> Thanks for creating & working on it! It definitely made adding scanner
> support fairly quick. libksane is the code (updated to use the attached
> patch) that I used to add this:
> http://monkeyiq.blogspot.com/2011/04/blocking-nostril.html
> 

:)


/Kåre