[open-beos-printing] Re: Updates?

Hi Michael,

thanks for your comments  :)  Hope you had some nice holidays too  :)

Michael Pfeiffer schrieb:

Hi Karsten!

2008/8/11 Julun <HOST.HAIKU@xxxxxx>

I have started playing around a bit with some new API for the print kit.

BPrinter: wraps currently around the old style printer nodes, but i would like 
to extend it to handle ppd informations as well.

Just to be a bit more specific, the ppd parser should no go in here. Only 
printer settings and some info about ppd file or driver location.


So it just provides a convenience API for the standard printer spooler
settings that are stored in file attributes (printer driver, transport
add-on, ...)?
How do you intend to support printer driver specific settings? For
example the path to the PPD file? Do you provide direct access to
BDirectory of the
spool folder or do you wrap that too?
I was uncertain on how to handle specific settings, even more i don't know yet what needs to be added once we have cups running. Do you have an rough idea whats needed?
I also can't see the need for direct access to the spool folder, as the printer is the spoolfolder. I added some watching methods to the printer class to monitor spooljobs. Most likely i will also add some more private methods to be able to use it from print server. Like i have added the config, job, page settings and so on. Not sure though. 




BPrinterRoster: can be used to retrieve printers from the system without 
print_server.


What's this for? ATM only printer_server or printers preflet could use
that, right?
Right, this was the indent behind it. Later I noticed that it could be handy for any app as well. It also has an inbuilt watching mechanism, so anyone can register and be up to date if a printer get's added. I used it to build the printer list in JobSetupPanel, but i will extend it to keep the printer list up to date. 




BPrintPanel, BJobSetupPanel (some missing panels): the idea here is to get rid 
of implementing these inside the driver (won't work with cups anyway).

Most likely they would use the ppd parser to get the printer options.


Yepp. It should be extensible by printer drivers. libprint already
provides this to a certain degree, but of course only for libprint
based printer drivers.
Currently it is not so much focused on drivers (but can be important), it was more like to help app developers to extend the panels. Like in ShowImage, when going to print there is this tiny small window between page setup and job setup, while the app dev would then be able to pass it directly to the job panel(this is impossible to achieve now): 

// the panels modifies the printer directly, not settings message around
BPageSetupPanel panel(&fPrinter);
status_t status = panel.Go();

BJobSetupPanel panel2(&fPrinter);

// create an advanced option preflet
BView* superduper = new SuperDuper();
panel2.AddOptionsPage(superduper);
status_t status2 = panel2.Go();

// then print based on printer settings
// like we have done with BPrintJob(still there, uses printer)
I still need to think how this special information can be stored, passed back.
Not sure how cups works, but i got the feeling that there is no need to talk with it like (BPrintJob <-> print_server). Hence the idea to put the panels on the application side and configure the printer object. BPrintjob might need to be extended to get all infos out of the printer and spool the job into the right cups folder. But i need to see how it works once available. 




Instead they should get the information from BPrinter and it set there as well. 
This would also allow to get rid of app settings storage in print server.


I still think coupling the settings with an application is a good
idea, so each application uses the settings it has used the last time
for printing. What's missing however are user definable presets (like
for color or black/white only). These should be configurable in the
printers preflet and in the print setup/job dialogs as well.


This is not entirely correct. I would offload the burden to the application 
developer which seems, hmmm...


I think this was intended by Be too. AFAIK Gobe stored these settings
within documents. I choose the app settings storage so neither the
application nor the printer driver has to care about it.
I think the current way is great, but what if we decide at some point we run only cups and no print_server anymore? 




I would also like to merge the preview and pdf printer as inbuild classes, so 
that, e.g preview printing works instantly without print to preview or tons of 
clicks in the printer panels. The same counts for pdf, it should be provided by 
default and always be available, but not as independent system printer.


Good idea, like it is available in Mac OS X? I think a good place
would be the settigs dialog opened by the print server. Where you
could add buttons for "preview" and "save to PDF file" and a
possibility to set PDF specific settings. Are there any PDF printers
available? If that's the case the PDF printer driver would still be
necessary.
I will only remove the need to setup a preview driver and print to preview. The pdf driver will still exist, but i consider sharing it, to have an always available print to file pdf printer. If one needs to setup an pdf printer, he can (even print to file). 



BTW these are acutally features for R2, but I don't want to stop you
if you have time to complete it before R1 is released :-)
I know that and this is fine with me. I never thought about doing this for R1. :) We haven't reached R1 yet, but i can not hurt to talk about this anyway. We will be even better prepared when we need to decide on an new API for after R1. :) 




PS: Any informations on the cups port?


Bad news: Jovan wanted to deliver the ppd parser one week ago, but I
have not received it yet...

Good news: CUPS almost builds out of the box under Haiku.


 Great  :)

 Only the

backend drivers need some work (= transport add-ons in Haiku). However
I did not test it. I could provide the Jamfiles if my MacBookPro did
not die last week :-( Of course no backups when needed.


Isn't there Time Machine on OS X? Sad, of course!  :(

Best Regards,
Karsten

Other related posts: