[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: libksane
From:       Thomas Gillespie <tomjamesgillespie () googlemail ! com>
Date:       2008-05-22 12:38:58
Message-ID: 200805221339.03402.tomjamesgillespie () googlemail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Kåre

> As I see it there is only a gui part. The non gui part would be the reading
> of the data it self (which is ~2 functions). All the parameter
> editing/setting is integrated into the gui.
> To save some memory it could be possible to make a "openDeviceNoWidget"
> that wouldn't create the widgets, but only read the available options and
> wait for a scan command.

The non gui part may not be a complicated class, with only functions for image 
grabbing, device selecting and parameter setting, but it would do all the hard 
work with sane, allowing the gui part to simply hook into this class, but also 
allowing developers to create  different gui's, more suited to their needs, 
without replicating the whole sane interfacing code.

> There I must disagree :) I don't think scan source, mode, bit depth and
> resolution can be too complicated/confusing.

Maybe confusing was the wrong word, 'unnecessary in some situations' may be a 
better phrase.

> But for stuff like archiving documents, there could be applications that
> would scan all the pages in an ADF, with specific settings, without user
> intervention. There a gui less interface would be better :)

Exactly, in fact this whole idea came from a small ocr app I was trying to 
build, where i simply want to grab the whole image in a resonably high 
resolution and then pass it to my main app. Here the needs are simple and 
almost all of the options are unnecessary for my needs. The KSaneWidget as it 
is seems a bit overkill for my needs.

Thanks

Tom


["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]