On Mon, 2010-11-22 at 12:53 -0800, Daniel Nicoletti wrote:
>If you do the work as a GObject, Python
>> bindings will be more or less
>automatic via gir.
>>
href="http://live.gnome.org/GObjectIntrospection" target=_blank
>> >http://live.gnome.org/GObjectIntrospection
The problem here is that GObject means glib which is not used in cups
server.
As I've said before, I think it quite unlikely that this would ever be
used by the CUPS server, but Michael Sweet would be the one with the
answer to that.
In any case, whether a particular library does or does not use glib is
only visible in terms of the dependencies pulled in. The end result
would include an XML parser, of course, so glib is hardly the final
straw when it comes to added dependencies!
well, at least to get all models iirc there is a get method for
that,
have to look at admin.c again.
Well, CUPS has no inherent notion of there being different models of
printer. It only knows about different PPDs. A given PPD can declare
its manufacturer (this is exposed by CUPS in the ppd-make attribute),
and its "nickname", i.e. a combination of the model name, possibly
including the manufacturer's name, and the driver used, often as well as
other bits of information. This is exposed by CUPS in the
ppd-make-and-model attribute.
This is why cupshelpers.ppds has a fairly expensive ppdMakeModelSplit()
function: in order to collect together PPDs which are for the same
physical printer model.
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.
What I see in master is both ppds.py and the xml.py thing
so I didn't knew ppds.py was deprecated.
No, ppds.py is not deprecated, but the interface it provides is
substantially different. The "old" interface gave only one PPD, the
"best", when matching a Device ID; the "new" interface gives an
ordered
list of all the appropriate drivers, in descending order of preference.
This allows the interface to present choices based on the Device ID from
the printer, something that allows the user to be more sure of getting
their printer to work.
For example, if a particular printer is driven by gutenprint (and
gutenprint declares the Device ID of that printer in its PPD), the
"best" printer driver might be gutenprint. But if that driver doesn't
work, the user has to look for other drivers. There may only be generic
drivers as alternatives, and we can only offer those based on the Device
ID's "CMD" field.
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.
>The work belongs in
> system-config-printer, not in pycups (which is just
>what it says and no
> more). There are already exported interfaces in
>system-config-printer
> such as the Python cupshelpers modules --
>including cupshelpers/ppds.py,
> which is what we're talking about.
well but in C you could access them through pycups which,
would be the same thing in the end I think.
I'm not sure I follow you. The pycups project is separate from
system-config-printer. They are separate tarballs, and have quite
distinct aims.
Well if it doesn't get accepted by upstream we can patch it
downstream easily I think. It would be pretty handy since
most printing servers I see the admins only use the cups server
interface.
I don't favour this approach at all. If it belongs in the CUPS server,
it should go in the CUPS server; if it does not, it shouldn't. I trust
Michael Sweet's judgement on whether it belongs there.
What would be the point of having a forked CUPS project with this extra
IPP operation? It could not be relied upon by anyone, since they would
need to be compatible with the "real" CUPS project as well.
Which "downstream" are you thinking of, in any case?
Tim.
*/