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