1:30 p.m.
So Tim,
I've talked with another kde dev,
and we are planning to translate the ppds.py to C.
As I said earlier:
Well IMO there is no much use for GetMakes, GetModels outside
printing tools, also if you do getPPDS you will already have them all.
I think the best thing to do would be to create a method like
IppResult* getBestPPDForID(char *id, IppResult *resultOfPPDS)
{
this way I can use my QCups class which handles the authentication
on cups for me (with DBus the user would have to authenticate twice)
then getAllPPDS and pass the cups result to here.
Cups server (631) could use this method easily.
here there would be the ppd.py code
And returning a new object of IppResult with the best matching ppds
ordered. ppds.py isn't that hard to convert here and once done, it would
be easier for most KDE devs (which most of them only know C/C++) to
help improving the matcher...
}
>>>>>
So what do you think of this? I think it's a good start,
if you can put this lib in py-cups binding we can work
latter on the XML thing that you are working on now.
Having this as a C lib might even be added directly in CUPS
thus maybe having Apple (cups devs) to help too.
It would be great if we could do an ippRequest(get-best-ppds)
on the server.
Best.
.................................
Hi Daniel,
It's great to hear that the KDE printing tools will be getting some more
traction.
On Fri, 2010-11-19 at 16:52 -0800, Daniel Nicoletti wrote:
Well I'm writing new printing tools for KDE with C++,
and the thing that these tools are missing is the logic
that the python ppd.py file has.
As we talked it would be great if that file were converted
to C, this way you could write your py bindings around it
I could use it easily in my KDE code and even
http://localhost:631 could use it.
What I've been trying to get to in preparation for system-config-printer
1.3 is the ability to have D-Bus activation for various parts of the
program. I've been concentrating so far on the UI parts (e.g. various
dialogs), but it would also be great to have an activatable system
service which would provide the interface from ppds.py.
That way it would be usable from any language. I think this would also
be the quickest way to make this code usable from any language, rather
than converting to the lowest common denominator.
I'm hoping to release 1.2.95 shortly which has several interface changes
compared to 1.2.4. In particular, with the PPDs class, there is a new
concept of "fit", i.e. how well the driver matches to a particular
printer. This is a better and more descriptive model than the status
codes used in 1.2.x. A new method, getPPDNamesFromDeviceID, returns the
complete set of candidate drivers for a given printer along with how
well each fits.
So we could have an interface "….Printing" with methods:
* "SplitMakeAndModel" for converting ppd-make-and-model strings into
separate strings for make and model, and
* "GetPPDsMatcher" for creating a new PPDs object for a particular
language and returning its object path
This PPDsMatcher object could itself have an interface containing:
* GetMakes, returning a UTF-8 string list
* GetModels, given a make, returning a UTF-8 string list
* GetInfoFromModel, returning a list of attributes given a make and
model
* GetInfoFromPPDName, returning a list of attributes given a PPD name
* GetPreferredPPDNamesFromDeviceID, returning a list of tuples of PPD
names and how well each fits, in preference order using the new
XML-driven method¹ (this would be a combination of
getPPDNamesFromDeviceID and orderPPDNamesByPreference)
Not entirely sure yet what the D-Bus signature for a list of attributes
would be: perhaps a{sav}, or perhaps something simpler.
What do you think about this approach?
Tim.
*/
________________________________
Daniel Nicoletti - KDE Developer
http://dantti.wordpress.com
When a wicked man dies, his hope perishes;
all he expected from his power comes to nothing. Prov. 11:7