[webkit-gtk] WebKit2 zoom API (II)

Gustavo Noronha Silva gns at gnome.org
Fri Feb 3 06:29:44 PST 2012

On Thu, 2012-02-02 at 16:52 +0100, Xan wrote:
> On Thu, Feb 2, 2012 at 3:30 PM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> > I still haven't heard of any use case where you want to set both scales
> > at the same time, all other ports don't allow it because it produces
> > unexpected odd results, so I still think we shouldn't support it.
> > However, I have a proposal to not block the API in this particular
> > decision:
> I also don't remember any use case mentioned in the other thread other
> than people saying some client had requested it. Perhaps my memory is
> failing me, but if there are valid use cases it would be useful to
> hear them.

That would be me. I really don't have any good reasons to give except
that some designers asked for it, indeed, so I guess we shouldn't worry
too much and if it turns out that some people need it they can modify
the behaviour for their specific project/device/whatever, or hopefully
the C API will not be thrown away =)

> >  - Rename current set_zoom_level and get_zoom_level as
> > set_page_zoom_level and get_page_zoom_level
> >  - Add set_text_zoom_level and get_text_zoom_level
> >  - We save both values, but when one is set, the other one is reset
> > (like it happens with apps calling
> > webkit_web_view_set_full_content_zoom() all the time before setting the
> > soom level)
> >  - That way we have both methods in the aPI and we avoid the setting.
> >  - If we eventually find a use case where it makes sense to set both at
> > the same time we can just change the behaviour without having to change
> > the API (just the impl and the documentation)
> >
> > Does it sound good?
> Unfortunately I think that still would count as an API break. Changing
> how the API behaves is an API break, even if your application still
> compiles. So it's not as safe as you make it sound, IMHO. Considering
> that I'm not really sure that it's worth it to change the current API,
> if I'm understanding things correctly.

I agree. Changing the behaviour after the fact would not do good for our
API stability promise =). If we aren't going to support setting both
zooms independently I see little value in having different functions for
that, I think that the setting and a single pair of zoom functions like
we have currently is a much cleaner API for what we want to support.


Gustavo Noronha Silva <gns at gnome.org>
GNOME Project

More information about the webkit-gtk mailing list