On Sat, 2010-11-20 at 11:30 -0800, Daniel Nicoletti wrote:
So Tim, I've talked with another kde dev, and we are planning to translate the ppds.py to C.
OK. Please bear in mind that you'll also need to convert cupshelpers/xmldriverprefs.py as well.
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?
If you do the work as a GObject, Python bindings will be more or less automatic via gir. http://live.gnome.org/GObjectIntrospection
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.
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? Also, in C, surely we'd be using real CUPS types such as ipp_t*?
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.
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.
The interface currently looks like this, excluding deprecated/obsolete parts:
ppdmakeModelSplit: string -> (string, string)
For converting a ppd-make-and-model string into separate make and model strings. This is more expensive than it sounds.
PPDs: constructor: with * result of CUPS-Get-PPDs * optional language name (for native language filtering) * optional XML directory for preferreddrivers.xml
getMakes: void -> string list
getModels: string -> string list
getInfoFromModel: (string, string) -> list of suitable PPDs (unordered)
getInfoFromPPDName: string -> PPD attributes
getPPDNamesFromDeviceID: (broken-down device-id, device-uri, device-make-and-model) -> dict of PPD name:fit
orderPPDNamesByPreference: all params from previous function plus list of downloaded file names to prefer -> sorted string list of PPD names
The downloaded file name thing is so that distributions using Jockey can automatically prefer drivers they've just downloaded (although there's no real reason they can't just look to see which drivers are new...).
So before starting, perhaps it would be nice to make sure the interface we're starting with makes sense. In that spirit, I'll suggest changing 'getPPDNamesFromDeviceID' so that it returns a list of (PPD name, fit) tuples, sorted by preference. That eliminates the need for orderPPDNamesByPreference.
==
How might the C interface look?
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.
Tim. */