[cups.development] GUI backend

Matthew Hipkin matthew at matthewhipkin.co.uk
Mon Apr 6 02:10:35 PDT 2009


Thanks all for your input, you've certainly given me some food for thought.
Am I right in assuming what you've described is going to be the same for
OSX aswell as Linux?


Till Kamppeter wrote:

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






More information about the cups mailing list