[Webkit-unassigned] [Bug 76448] [GTK] Add WebKitPrintOperation to WebKit2 GTK+ API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76448





--- Comment #6 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-02-13 05:32:56 PST ---
(In reply to comment #5)
> (From update of attachment 122759 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=122759&action=review
> 
> > Source/WebKit2/UIProcess/API/gtk/WebKitPrintOperation.cpp:251
> > +    bool doPrint = webkitPrintOperationRunDialogUnix(printOperation, parent);
> 
> How about shouldPrint?

Sounds good too.

> > Source/WebKit2/UIProcess/API/gtk/WebKitPrintOperation.cpp:371
> > +void webkit_print_operation_run_dialog(WebKitPrintOperation* printOperation, GtkWindow* parent)
> 
> Not sure about this. Blocking on this function is not very elegant I think (although it is indeed what GtkPrintOperation would do).

I read somewhere that print is supposed to be a sync operation. All browsers I've tested show a modal print dialog (chromium, ephy, firefox, arora, ...). GtkPrintOperation can run the dialog asynchronouslym in unix. 

> Two options I'd like us to consider: a non-blocking _present_dialog() with the same parameters that shows the dialog but instead of running the main loop connects to signals and handles everything automatically,

This is possible in unix, but not in win32.

> or a way to obtain the dialog and show it ourselves, with a _print() call that does the actual printing.

Again, this can't be done in win32.

> Do you see a problem with any of those? Or do you think this use case is already handled by the API user showing a dialog themselves and then using webkit_print_operation_print() from bug 76536?

That's a possibility, although that api is thought to print without showing any print dialog at all, nothing prevents the uiser to implement their own printing dialog and call webkit_print_operation_print(). 

> 
> > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:573
> > +     * Emitted when printing is requested on @web_view, usually by a javascript call,
> > +     * before the print dialog is shown. This signal can be used to set the initial
> > +     * print settings and page setup of @print_operation, by calling
> > +     * webkit_print_operation_set_print_settings() and webkit_print_operation_set_page_setup().
> > +     *
> > +     * You can connect to this signal and return %TRUE to cancel the print operation.
> 
> So, when I set the default settings, do I return FALSE to not cancel the operation? I guess so from the code, but the doc is a bit confusing.

Yes, the next line in the docs says:

Returns: %TRUE to stop other handlers from being invoked for the event. %FALSE to propagate the event further.

So, you always have to return FALSE if you want the even to be propagated. I'll try to explain it better anyway. 

> > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:106
> > +    gboolean   (* script_prompt)  (WebKitWebView         *web_view,
> > +                                   const gchar           *message,
> > +                                   const gchar           *default_text,
> > +                                   gchar                **text);
> > +
> > +    gboolean   (* print_requested) (WebKitWebView        *web_view,
> > +                                    WebKitPrintOperation *print_operation);
> 
> They seem to be misaligned by one.

Right.

> > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.h:213
> > +
> 
> Extra line intended?

Nope :-P

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.