[cups.development] GUI backend

[Till Kamppeter]

HP does this in HPLIP. Their GUI part is listening on the D-Bus and the 
fax CUPS backend communicates with GUI via the D-Bus, passing the job 
over to the GUI. Then the GUI for sending faxes opens and allows the 
user to choose a cover page, fax numbers, and additional files to fax 
and sends everything to the fax-capable MF device.

    Till


Matthew Hipkin wrote:
> alet at librelogiciel.com wrote:
> 
>> On Sun, Apr 05, 2009 at 02:33:01AM -0700, Matthew Hipkin wrote:
>>> Hi
>>>
>>> Is it possible to create a backend for CUPS that has a GUI? For testing I
>>> tried modifying the pdf distiller backend to invoke a test application,
>>> the modified script ran as it usually does, it didn't invoke the test app
>>> (I coded various log functions which were never called) but still
>>> returned exitcode 0.
>>>
>>> Any pointers would be appreciated, I'm running CUPS 1.2.12 on Fedora 7.
>> Usually you can't do this because CUPS is launched well before any
>> graphical environment so your backend wouldn't know "where" to display.
>>
>> But you can do a popular trick which consists in  splitting your backend
>> in two parts :
>>
>>  - The first part handles all the GUI related stuff, and waits for
>>    incoming connections from the second part. This part is launched
>>    whenever your end users opens a graphical session.
>>
>>  - The second part, which is your real CUPS backend, guesses (from job's
>>    attributes for example) where the first part is, and dialogs with it
>>    over any mean of your choice.
>>
>> >From experience this works just fine.
>>
>> There are a few things to take care of however, like ensuring your GUI
>> doesn't block your backend from processing other jobs (like if the user in
>> front of the GUI goes away when you're waiting for him to click on
>> OK). Finally you must understand that your GUI won't be called by your
>> backend as soon as you submit a new print job, but only when both CUPS
>> will have finished to appply its chain of filters to this job's datas, and
>> when the previous job has finished to be printed.
>>
>>
>> bye
>>
>> Jerome Alet
> 
> Thanks for the advice, seems like I totally underestimated this.