[webkit-gtk] WebKit2 zoom API

Carlos Garcia Campos cgarcia at igalia.com
Thu Dec 29 00:11:08 PST 2011

El mié, 28-12-2011 a las 16:59 -0800, Martin Robinson escribió:
> On Tue, Dec 27, 2011 at 11:50 PM, Carlos Garcia Campos
> <cgarcia at igalia.com> wrote:
> > I guess form controls are scaled because they contain text. The C API is
> > WKPageSetTextZoomFactor(), the WebCore API is Frame::textZoomFactor()
> > and Mac API is setTextSizeMultiplier() and the method
> > _setZoomMultiplier() uses a preference called zoomsTextOnly to decide.
> This seems like a reasonable name then. Another thing I think we
> should at least discuss is that this API prevents having both a text
> zoom and a full-page zoom concurrently. This is something that the C
> API allows.

is there a use case where changing text and page zoom at the same is

> It seems that internally text and page zoom factors are per-frame
> decisions, not per WebView. My guess is that this is why it doesn't
> hang off of Settings.h.

Not really, API doesn't allow you to change the zoom factor of a
specific frame, you can only change that for a page, so that the zoom
factor is applied to the main frame that recursively applies the same
zoom factor to all of its children frames. So in the end zoom factor is
a per-webview decision, and it's part of the WebView API in all ports.

>  The more I look at this API, the less I see
> any reason to deviate from the C API here.

I don't think we have to make our API confusing or more complex just
because the C API is. 

> What's wrong with this?
> webkit_web_view_supports_page_zoom
> webkit_web_view_set_page_zoom_factor
> webkit_web_view_get_page_zoom_factor
> webkit_web_view_supports_text_zoom
> webkit_web_view_set_text_zoom_factor
> webkit_web_view_get_text_zoom_factor

so, if we decide to add zoom_in/out methods we would end up with 4
methods more, text_zoom_in/out and page_zoom_in/out. I find it very
confusing, users expose only one zoom control in their UIs and they
decide whether it affects only the text or not, but I can't think of any
use case where it's needed to change both at the same time or even
expose two zoom controls (one for text and one for the page). If you set
textZoomFactor to 1.5 for example, and pageZoomFactor to 2.0, first the
text will be scaled to 1.5 and then it will be scaled again to 2.0 (so
the text will be scaled to 1.5 * 2.0), we would need to document that.

The mac API has these methods:
 - setTextSizeMultiplier
 - textSizeMultiplier
 - makeTextLarger
 - makeTextStandardSize
 - makeTextSmaller

In all those methods a preference zoomsTextOnly is used to decide
whether to use page or text zoom factor. I find it even more confusing,
since the API says text and zoomsTextOnly is NO by default. It's true
that in both cases the text is always scaled, but I would avoid using
text in the API and just use zoom_level which is what our WK1 API says
and what (I think) our users expect.

> --Martin

Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20111229/1828eaf6/attachment.bin>

More information about the webkit-gtk mailing list