[webkit-gtk] RFC: Improving FrameLoader signals

Gustavo Noronha Silva gns at gnome.org
Tue Jun 1 10:33:15 PDT 2010

Hey, hey,

On Fri, 2010-05-28 at 17:14 +0200, Martin Robinson wrote:
> Today I did a quick audit of the frame loader signals we do have and compared
> it to the Mac port. Our signals have come a long way, but I feel we can improve
> them still. Attached is a very rough proposal. I'd love to get some feedback/
> hatemail.

You are a #(*$&(*$&Q# $$(*#Q&(*$#Q&$#Q. Just kidding ;), I prefer
feedback. I really like the proposal! I was actually advocating
something along these lines a few months ago. I think we should add all
this stuff, and get some practice with them implementing testing in
DRT/API tests to get a feel.

> A couple things:
> state from load-status, as it's really more of an event than a state
> the frame is
> in. In the timeline of a load, I'm not sure if there is any guarantee that this
> happens before or after load completion. This forces clients to keep track
> of state outside the view as well. The frame shouldn't throw that information
> away.

I see your problem with this, and I tend to agree now that I think about
it under the light of what you said. Unfortunately, since we added this
for 1.2, we will have to deprecate it for 1.4, and then remove it from
1.5 onwards, according to our API plans. I am not against that. We can
add a separate property that exposes the state of the frame with regards
to layout/rendering, I guess, for uses that rely on it.

> If people like the idea of adding more signals, perhaps we should keep
> them all private for now and add them to the API as they stabilize (there is no
> saying FrameLoaderClient will not make them disappear in the future). DRT,
> etc can use them for the time being.

Yes, please. Let me know of patches implementing this =D


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

More information about the webkit-gtk mailing list