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