[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-21 19:57:08
Message-ID: 200805212057.12890.tomjamesgillespie () googlemail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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?

> 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.

> Now I also want to mention that I don't know in advance what options the
> sane backend provides. Some backends have a lot of parameters while others
> have few and all the options that appear on the KSaneWidget depend on the
> backend.

Is there a specified set of features that may be available? If this is the 
case you could just have functions querying if they are available. If not 
maybe something could be worked out with QObject dynamic properties? I'm just 
playing with ideas, maybe theres a better way.

Thanks for you time

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]