On Tue, 2010-11-23 at 07:50 -0800, Daniel Nicoletti wrote:
Ok please look at this file: http://websvn.kde.org/trunk/playground/base/print-manager/libqcups/PPDModel....
Are you saying that I can't trust on ppd-make string to have the manufacturer? I can filter all my ppds by it's make without running any expensive task, if you can install kdelibs-devel and qt4-devel you can try my code to see how the ppd choser works now.
I'm saying that in order to find the model, you need to perform lots of operations on the ppd-make-and-model field. It isn't just taking off ppd-make from the beginning.
Well first to get the devices (done by qcups) and then to get the ppds list (done by pppds.py).
Ah. But cupshelpers.ppds doesn't interact with the CUPS service at all. It only processes an IPP result. Think of the PPDs object as the representation of a set of PPDs, and the actions you'd like to perform with them.
See this is the problem, how would you get an ippResult that I got with my bindings?
Well, from libcups. If we're talking about having cupshelpers.ppds re-implementated as a C library, I don't see what's wrong with that part of the interface. It can just take 'ipp_t* ppds', i.e. the result of a CUPS-Get-PPDs query, as a parameter.
Another important change is that instead of having a status code to describe how well the driver matches to the printer, now a string is used, the "fit", e.g. "exact-cmd" (meaning that the model name matches exactly, and the CMD field positively matches the declared command sets of the PPD), "exact" (meaning just that model name matches), etc. This provides more information than the status codes.
Sure that's good, though I think maybe a percentage value would be nice, so we could display a set of stars.
But a percentage of what? I think the string descriptions are best.
Tim. */