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