Re: Gtk+ printing dialog highlevel thoughts

[Alexander Larsson <alexl redhat com>]

On Thu, 2006-01-19 at 15:57 -0500, Jonathan Blandford wrote:

> At the Boston summit, we came to the opposite conclusion.  We looked at
> a random windows installation, and it seemed like every application had
> a different print dialog.  Even on OS/X, there was a lot of variety.  If
> we did go with the 'native' dialog, it wasn't empirically clear which
> native dialog that would be.  It may be easier anyway to use it, but
> consistency is a bad argument here.
> 
> The driver-specific options is a better argument for that, though.

Yeah, I do think it will be hard to get get a non-native dialog working
on Windows, although it might be possible on OSX (given that they make
the cups api etc availible). But even in the OSX case you'd be missing
out driver specific printer dialog extensions.

> > The print dialog implementation has two parts. First the generic
> > portable API with implementations for the platform native dialogs, 
> > then the "native" dialog for Unix. In order to support the "Using the
> > Gtk+ dialog as a native print dialog" use-case we probably need to
> > expose this as a platform-specific api, with accessors similar to the
> > ones we have for accessing e.g. the win32 print dialog object. 
> 
> So typical code would be something like:
> 
> #ifdef WIN32
> dialog = gtk_win32_print_dialog_new ();
> if (gtk_win32_print_dialog_run (dialog) == GTK_RESPONSE_OK)
>    ...;
> #else 
> dialog = gtk_print_dialog_new();
> if (gtk_dialog_run (dialog) == GTK_RESPONSE_OK) 
>    ...;
> #endif
> 
> Would we expect all the various gtk_print_dialog_* functions to be
> available?  For the native functions, or will every app running on Win32
> have to special case printing?

No, thats not quite what I mean. First of all the API will likely not be
exposing dialog objects like that. Instead it'd look something a bit
like this:

print_op = gtk_print_operation_new();
gtk_print_operation_set_default_page_settings (print_op, page_settings);
g_signal_connect (print_op, "draw-page", draw_page_cb);
res = gtk_print_operation_go(); 

The last line would open the dialog, and when the user clicks print the
callback will be used to do the rendering and the job will be sent to
the printer.

The above is what i mean by the "generic API". What I mean by win32
specific code is to allow replacing the last line with something like:

PRINTDLGEX pd = { blah..};
res = PrintDlgEx(&pd);
if (res == S_OK && pd.dwResultAction == PD_RESULT_PRINT) {
  gtk_print_operation_go_from_win32_dc (pd.hDC, pd.hDevMode);
}

I.E, allow the app to do any win32 specific stuff it wants, but then
chain that into the standard gtk+ print chain. This all has to be done
internally to handle the native print dialog anyway, its just a matter
of exposing it correctly.

When i talk of the "second part" of the api I mean something vaguely
like:

GtkWidget *gtk_cups_print_dialog_new ();
char *gtk_cups_print_dialog_get_cups_printer_name ();

These calls are availible only on some platforms. This API would be on a
similar standing with PrintDlgEx on win32 (i.e. they are the native
print dialog implementation). You can use it alone, or chain it into the
standard gtk+ print chain (although that shouldn't be needed).

> At the summit, we thought evince would be perfect for this.  There are
> patches floating around to make evince compile on Windows, so we could
> even distribute it there.  For OS/X, we could (of course) use preview
> itself.
> 
> The one problem with this approach, is that the 'Preview' button
> requires you to generate the full document before sending it out to
> evince.  This is obviously going to be slower (and sometimes, much
> slower) than previewing individual pages on the fly.  
> 
> Also, there's the danger of introducing drawing errors in the flow of:
> 
> App -> cairo -> pdf -> pdf parser (poppler) -> cairo -> screen
> 
> That being said, we want a good pdf library anyway, so we shouldn't hold
> off on this for that reason.

I think OSX does both forms of preview, which might be an interesting
approach. One for the small widget preview inside the print dialog, the
other is for the preview.app full-scale separate window mode.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fiendish moralistic paramedic haunted by an iconic dead American 
confidante She's a cold-hearted snooty fairy princess on the trail of a serial 
killer. They fight crime!