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

List:       kde-devel
Subject:    Re: libksane
From:       Kåre_Särs <kare.sars () kolumbus ! fi>
Date:       2008-05-22 7:30:28
Message-ID: 200805221030.28871.kare.sars () kolumbus ! fi
[Download RAW message or body]

Hi Tom,

On Wednesday 21 May 2008, Thomas Gillespie wrote:
> Hi Kåre
>
> > There could be a possibility to just not show the KSaneWidget and provide
> > a function that would trigger the scanning.
>
> Wouldnt it be easier and cleaner just to split the code into two classes?
> The gui part and the non gui part? It just seems neater that way, what do
> you think?

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.

Maybe even so that "openDevice" would create/return a QWidget and not so that 
KSaneWidget inherits QWidget.

>
> > I have been thinking about adding a way to save the current options so
> > that they could be restored the next time the application is run. The
> > idea is that the option names and values would be returned as strings to
> > the application and that those strings then could be used to set the
> > values. This could probably also be used for setting desired values for a
> > widgetless scan.
>
> I like this idea, the options could then be set by the programmer if the
> application's scanning needs arent that complicated, saving the user a lot
> of confusion.
There I must disagree :) I don't think scan source, mode, bit depth and 
resolution can be too complicated/confusing.

(OK 'bit depth' could be the exception, but if that is the case I could move 
it to the "Other Options tab".)

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 :)

-- 
Kåre Särs
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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