Re: Print preview

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

On Tue, 2006-05-16 at 09:25 -0400, Matthias Clasen wrote:
> A lot of good arguments for and against external preview have been made
> in the last few days, which has certainly made it clear that there are benefits
> and drawbacks to either approach. It seems clear that no solution is optimal
> for all situations.
> 
> I'd like to propose that we go with and external preview application for 2.10
> (if only for schedule reasons), but add api that lets applications
> take over the
> handling of the preview if they want. Further down the road, if a really good
> preview widget appears (such a widget chould probably lend a lot of code
> from the current libgnomeprintui preview),  we can integrate it and make
> "internal previewer" one of the possible choices for the preview setting.

I think this is a good track.  Since there seems to be people very
interested in a preview widget who understand the issues better than I,
they can work on providing a patch while allowing GTK to not block on
the preview issue.

> Since John already has a good start on getting the external previewer
> to work, I guess the next question is, how would a minimal api look like
> that lets apps take over the preview ? One thing that comes to mind
> is a
> 
> gboolean ( *preview) (GtkPrintOperation *operation,
>                                     ...)
> 
> signal. What else is needed ?

Alex had the idea that we should just provide a default signal handler
and let the app override it instead using the magic gboolean return to
determine if the app will take over.

This is all off the top of my head right now:

I think we need to define a way to hook into the rendering facilities,
so something like render_preview_page(n, surface).  This way an app can
use its own preview widget and the internal widget would use the same
API.  We could have a create_preview_widget API but I think that can
wait until there is an actual preview widget.  

We need to be able to render preview pages without messing with the
internal state of the PrintOperation so this would all benefit the
evince preview method.  Right now we preview by using the print API and
dismissing the dialog.  What we want to do is special case preview,
again so it doesn't mess with the internal state of the
PrintOperation.    

Of course another option would be to just create another PrintOperation
for each preview so we don't have to worry about state.  I'm not sure if
it will work, but I don't see why not.

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