[Webkit-unassigned] [Bug 22898] [GTK] Patch to complete GtkPrint API

[bugzilla-daemon at webkit.org]

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





------- Comment #19 from gns at gnome.org  2009-03-11 13:59 PDT -------
(In reply to comment #18)
> > I wonder if it is useful at all to support GTK+ versions < 2.10 since we are
> > now requiring such a recent libsoup, for instance.
> 
> I've been specifically asked for GTK < 2.10 support (or rather API
> compatilibity). It doesn't add much to the patch.

By who? With what rationale? It's just a small amount of code, indeed, but I am
not convinced we need it at all.

> The current patch already provides good control in my opinion, and even if it
> needs two API methods, this way seems more straight-forward for application
> developers (at least to me) than having to setup a signal callback which will
> probably require a specific structure to pass GtkPrintSettings and GtkPageSetup
> back and forth.

I think passing a GtkPrintOperation, really, much in the same way the
create-web-view does with WebKitWebView. I am worried that we limit the amount
of control the application has regarding the printing process - for instance,
displaying progress.

> Printing to file is already possible from within the print dialog, so
> application developers who only need to print on user's request should be fine
> with the existing implementation anyway, or with this implemenation using only
> one API method (webkit_web_frame_print).
> 
> The goal of this patch is to be able to print to file without user interaction
> at all.

Right. The way I understand this, though, ChromeClient::print may be called by
javascript code requesting printing, for instance. The current implementation
will popup the print dialog if this happens, which may not be what the
application intends - it may just as well want to print to a file
automatically, with an automatically-generated name, or send the job with a
pre-defined configuration to a pre-defined printer.

Coupled with my worries about the amount of control the application is able to
have regarding the printing process as a whole, I wonder if adding a
print-requested signal or something like that, which expects the client to give
it an already setup GtkPrintOperation is not the way to go.


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