[webkit-gtk] WebKit2 zoom API (II)

Mario Sanchez Prada msanchez at igalia.com
Tue Feb 7 03:10:01 PST 2012

On Thu, 2012-02-02 at 19:54 +0100, Xan wrote:
> On Thu, Feb 2, 2012 at 6:36 PM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> >> Does not look like the most elegant API in the world to me.
> >
> > Agree, problem is, what is the effective zoom initially when both scale
> > factor are 1?
> Yes. I guess in this case we would need an enum like NONE/TEXT/PAGE,
> with NONE used when both scale factors are at their default value.

I was about to say the same thing: we probably need to store somewhere
else the zoom mode currently in use, and return it when requested.

> >>  I suppose
> >> that if we consider a getter of the active zoom useful it can always
> >> be written later using that algorithm inside WebKitGTK+ though.
> >
> > In any case, as I said, most of the apps use one scale factor or the
> > other, so they don't need to know the effective one. Apps that want to
> > scale text will use set/get_text_zoom_level and apps that want to scale
> > page content will use gt/set_page_zoom_level. An apps that have a
> > preference to control it, already know the effective zoom too.

Probably I'm thinking too much of a corner case, but I can imagine a
case where someone can make the most of the ability to combine those two
types of zooming modes. For instance, consider the following:

  1. We start at text and page zoom levels set to 1.0x
  2. The user sees it as too small and so starts zooming the whole page 
     up to twice its size. So everything gets bigger: images and text.
  3. With page zoom level at 2.0x images are already big enough for the 
     user, but the text is not there yet. Feels like it needs more 
     zoom, but only for the text, since the user doesn't want the images
     to keep growing, as it would probably screw the rendered result.
  4. Providing the app allows the user to do it so, and so that 
     WebKitGTK+ provides the API for that, the user zooms now the text 
     only, up to 1.5x its size (on top of the 2.0x page zoom level)
  5. End result would be:
      - orig. zoom level: 1.0 |
      - text zoom level: 1.5x |=> effective text zoom level: 2.4x
      - page zoom level: 2.0x |

I recognize perhaps it's a little bit too special use case, but I think
people could themselves in this situation, specially in some websites
that make not the best use out there of font sizes.

> Probably, yes. In any case as I said I think it's safe to see whether
> the method I mentioned is requested or not before adding it, since it
> seems possible to add it after the fact.

I'm not sure if there would be much demand on that method since, after
all, I think it could be easily calculated from current page and zoom
levels. Anyway, I don't see much trouble in adding it later if needed,
so I wouldn't rush it now either.


More information about the webkit-gtk mailing list