Re: [gedit-list] First pass hack of gedit and gtksourceview port to gtkprintoperation

["Matthias Clasen" <matthias clasen gmail com>]

On 4/29/06, Paolo Borelli <pborelli katamail com> wrote:
> I have not looked at the patches very carefully yet (btw, I get crashes
> when trying to print), but at a first look there are some generic issues
> which I think are worth raising as soon as possible since they may be
> related to the new API.
>
> As far as I can see with your patches the pagination happens
> synchronously, in the begin_print callback. This is a showstopper since
> it means that it will block the UI for several seconds when paginating a
> long document.
> I may be wrong but this assumption seems hardwired in API since you need
> to set the number of pages before running the operation and to know the
> number of pages you need to paginate.
>
> In this regard, I am probably missing something but I see a kind of
> chicken end egg problem in the api: as said above it looks like
> pagination needs to happen before the dialog is run, but to paginate
> correctly we need to retrieve the settings from the dialog itself.

The number of pages is required to be set before the actual rendering
starts. It is not absolutely required when running the dialog (and, as you
said, the settings in the dialog may affect the pagination...). We emit
the ::begin-print signal after the dialog is done, but before the rendering
starts. At that point, the settings are known.

In simple cases, it might be possible to paginate-as-you-go, and render
pages until you run out of text, but in general, I think it is reasonable
to assume that documents need to be completely paginated before
printing starts (think about page number references in TOCs, running
heads, etc).

I'm not sure what is the best way to avoid problems with pagination
blocking the ui for a long time. Alex opened a bug about allowing rendering
to happen in a thread.

Matthias