Re: Gtk+ print support - request for feedback

Alex Graveley wrote:

Thought it would be vauable to get some non-gtk eyes on this great work. I've cc'd Till Kamppeter, who leads, and Michael Sweet, the CUPS dude.

I'm kindof deep in the CUPS 1.2 release process right now, but I took
a quick look at the CUPS stuff and have some implementation comments...

Alexander Larsson wrote:
* eggcupsutils.[ch]

egg_cups_reqeust_encode_option(): It would probably be better to
just use cupsEncodeOptions() with a local cups_option_t variable,

    cups_option_t cups_option;  = option;
    cups_option.value = value;

    cupsEncodeOptions(request->ipp_request, 1, &cups_option);

You are also not putting the attributes in the right group (all
job template attributes go in IPP_TAG_JOB; the only exceptions are
the compression and document-format attributes, which are part of
the operation group (because the attributes belong to the document,
not the job...)  You'll notice that we handle document-format
specially in CUPS 1.1.x, and compression and document-format in 1.2
which has a new cupsEncodeOptions2() API to control which groups
get added, too...

Mind you, *right now* CUPS does not require the options to be in a
specific group, but that may change should we run into other problems
that require stricter IPP conformance.

_post_check() and _get_check(): use cupsDoAuthentication and register
a password callback which can, initially, just return NULL until you
implement the necessary dialog...

* eggprintbackendcups.[ch]

CUPS 1.2 adds some new APIs that should be used if they are available:
httpAssembleURIf(), httpGetHostname(), and httpSeparateURI()

Pass cupsUser() in a requesting-user-name attribute when you do the
CUPS_GET_PRINTERS request, or use cupsGetDests2() to get the list of

_cups_request_ppd() needs to lookup the printer-uri-supported value
to get the proper server to request the PPD from, otherwise you won't
work with remote printers or (implicit) classes. The cupsGetPPD2()
function does this for you, of course, but is not asynchronous...

ppd_text_to_utf8() leaks memory for UTF-8 encoded text - you can
set encoding to a constant string there, too!

I think you'll find the hardcoded option list approach to be a dead-end.
It works for basic/common options that you want on the main page, but
the "advanced" properties need to use something that isn't compiled in,
such as the UI group from the PPD file.

Don't limit the number of choices based on conflicts/constraints -
otherwise you WILL end up dead-locking users so they have no way to
access a particular option.

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]