Bug 16493
Summary: | [GTK] Provide a public printing API | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alp Toker <alp> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Enhancement | CC: | chpe, christian, Don, mbarnes |
Priority: | P2 | Keywords: | Cairo, Gtk |
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All |
Alp Toker
Printing can only be triggered by JS through ChromeClient right now. The API remains internal until we can provide a well-designed, extensible printing interface that accommodates browsers, document viewers, email clients etc. including support for custom headers and footers.
Investigations here should centre around existing GTK+ widgets, the GtkPrint API, printing solutions in browsers like Epiphany and widgets like GtkHtml and its use in Evolution.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Alp Toker
GtkSourceView 2 (the new version) apparently has a nice API for this. We should also look at other browsers and widgets.
Matthew Barnes
I helped port GtkHTML from GnomePrint to GtkPrint. Here's what I'd recommend as an incremental improvement to webkit_web_frame_print(), similar to what we did for GtkHTML (ignoring header and footer support):
WEBKIT_API GtkPrintOperationResult
webkit_web_frame_print (WebKitWebFrame *frame,
GtkPrintOperation *operation,
GtkPrintOperationAction action,
GError **error);
The most important thing here is to allow applications to create their own GtkPrintOperation, configure it with their own print settings from GConf or wherever, and then pass it on to WebKit. All WebKit needs to do is connect to GtkPrintOperation signals, call gtk_print_operation_run() and return the result.
Also, don't run an error dialog yourself. Just return the print result and let the application deal with GTK_PRINT_OPERATION_RESULT_ERROR.
GtkHTML's new printing API (ignoring the deprecated stuff) consists of a single function similar to above and I think it's worked out quite nicely.
Alp Toker
(In reply to comment #2)
> I helped port GtkHTML from GnomePrint to GtkPrint. Here's what I'd recommend
> as an incremental improvement to webkit_web_frame_print(), similar to what we
> did for GtkHTML (ignoring header and footer support):
>
> WEBKIT_API GtkPrintOperationResult
> webkit_web_frame_print (WebKitWebFrame *frame,
> GtkPrintOperation *operation,
> GtkPrintOperationAction action,
> GError **error);
>
Thanks for this proposal. There's one thing I haven't been able to decide that stopped me from implementing it..
We were originally hoping to make WebFrame independent of GTK+ (only using GLib) so it could be used in non GTK+/console GLib applications. If we add the print API to WebFrame, that plan needs to be re-thought.
If we put the print API on WebView, we end up restricting the API only allowing the main frame to be printed.
I have a feeling there's another simple way of doing this we've missed so far. Will think about it some more.
Matthew Barnes
Pitched an idea for supporting page headers and footers directly in GtkPrint. Thought you might be interested.
http://bugzilla.gnome.org/show_bug.cgi?id=522708
Alp Toker
Some applications (Devhelp, Epiphany) are using this as a pretty workable solution for now:
webkit_web_view_execute_script (web_view, "print();");
This will pop up a GtkPrint window with the user's default print settings, including a print preview button.
Gustavo Noronha (kov)
Another bug has been opened to deal with this; since the patch is in the other bug I'll close this one as a duplicate.
*** This bug has been marked as a duplicate of 22898 ***