Re: [patch] Print Preview

["John (J5) Palmieri" <johnp redhat com>]

On Fri, 2006-05-12 at 12:47 +0200, Alexander Larsson wrote:
> On Thu, 2006-05-11 at 21:07 -0400, John (J5) Palmieri wrote:
> > Here is my patch for print preview.  I haven't created the signal yet
> > but that should be a trivial change.  Right now we just work as if the
> > user hit print.  The dialog is dismissed and evince (or whatever is
> > configured as the gtk-print-preview-command settings property) is
> > launched.  We default to "evince %f".  The dialog dismissal works like
> > MacOSX works.  I'm not sure if we want to keep the print dialog around
> > anymore.
> 
> Is this really what you expect? Closing the print dialog when showing
> the preview seems kind of surprising to me. I'd expect it to show the
> preview, and when you close that you can continue to tweak the settings.
> Also, this is very visible in the API, with the print operation actually
> terminating (forcing you to either forget the changes to the settings,
> or save "non-final" settings). 

Closing/not closing is a separate issue from losing settings.  We
obviously want to retain settings and the current code was just to get a
feel for how preview would work.  I absolutely agree that we need to go
a slightly separate route from how we do actual printing and preview.
As for closing, MacOSX does this and may retain the settings in their
preview app.  Either way we should get the code to be able to do both
and then decide which is better. 

> Btw. the way this integrates with the print loop is probably gonna be
> affected by the async changes that has been discussed.

Is there a concrete way this is going to work?  It should be easy to
adapt the preview code to.

> Is using the pdf printing backend really needed to do the print preview?
> Isn't something similar to gtk_print_operation_set_pdf_target() good
> enough?

You can't do that right now.  The gtk_print_operation_set_pdf_target
code only gets executed if you set the dialog not to display so it would
need to be re-factored a bit.  I kind of like having everything run
through the same codepath though, it allows us to find bugs and optimize
more efficiently.  I'm not married to using the backend.  One thought
was to just create a new GtkPrintOperation for the preview.

> One issue with having the print preview not terminating the print
> operation is that apps will have to handle the print loop running
> multiple times in one print-operation.

Yes, of course spawning a new GtkPrintOperation would allow us to make
sure we don't trample on the state of the current print operation.  

-- 
John (J5) Palmieri <johnp redhat com>