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.
Ok, I didn't know that.
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.
Right, that's why I was saying libqcups using your pppds.py wouldn't work as we could not glue the ppds (at least not without a second auth). So if you are okay with we re-implementing this as a C lib, just tell us which files should go first so that we don't rewrite obsolete code. I really wish I could have something this year cause next year I'll probably be moving abroad and I'm not sure of how much free time I'll have :P
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.
A right, I was thinking at the code I saw that had some numeric metrics, so the idea is just to have a set of strings that can be translated into fit, exact... ok got it :D
Ok I think we are fine then were do you think the development should take place? We can start the code together with our kde tools so we can more easily test and then move to somewhere else. Print-manger is moving from kde svn to kde's git so I guess pushing that to fedora's git would be easier also.. what do you think?
Best, Daniel.