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