2:53 p.m.
OK. Please bear in mind that you'll
> also need to convert
cupshelpers/xmldriverprefs.py as well.
Sure,
It would
> be great to have this work in progress go in a branch from
master. Will
> you have your own git repository tracking it, or be
working in the main
> fedoraproject.org git repository?
I think creating this branch is best, though to be honest,
the end of year is a rush, and I'm not sure I'll have time again
to work on this ... kde ppl will kill me :P
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.
By converting the entire
> thing to C, you'll still need to preserve the
core methods such as getMakes
and getModels. You don't get them
automatically from CUPS-Get-PPDs,
just a list of ppd-make-and-model
strings. In simply providing the
other interface methods, these lists
of makes and models have to be
calculated -- hiding them just means the
work has to be duplicated elsewhere
in the program.
well, at least to get all models iirc there is a get method for that,
have to look at admin.c again.
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
Why do you say that D-Bus would require the user to authenticate
twice?
Well first to get the devices (done by qcups) and then to get the ppds list
(done by pppds.py).
Also, in C, surely we'd be using real CUPS types such as
ipp_t*?
yes cups types it's just that I forgot the name of the type.
> 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.
I don't see the
point in starting with old code. Why not use what's
currently in
master? It will be more than double the work if you have
to redo it,
not least because the interface is different.
What I see in master is both ppds.py and the xml.py thing
so I didn't knew ppds.py was deprecated.
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.
How might the C interface
look?
well surely you know these methods better that I do,
but I think we can have them all and using the cups types
to make it easy to play with.
> Having this as a C lib might even be added directly in
> CUPS
> thus maybe having Apple (cups devs) to help too.
I really
don't think that would happen, but you'd have to talk to
Michael Sweet.
Choosing a "best" driver has long been something that
the CUPS server is
neutral on.
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.
Best,
Daniel.