On Fri, Feb 3, 2012 at 10:44 AM, lkcl luke <[email protected]> wrote:
>
> full source code is in the pyjamaslamson repository, yes it works as
> a pyjd application (except now of course it _won't_ work because it's
> only possible to load one app once and only once per pyjd session, now
> you get why sorting that problem out in pyjd is so important,
> anthony).
yeah i'm still playing around with mail app, and other things along the way ...
i did take a look at the double load problem last night -- it's not
100% clear why it doesn't occur *more* times than it is, buy i'm
mostly confident the problem is due to <iframes>. if i remove the
bootstrap,js file completely, i only get a single load. if i comment
out the single line in tha JS file that appends the nocache <iframe>,
i only get a single load. however, if i directly connect to the real
WebKitWebView object, and use an `onload-event` (or possibly the
document-* one), then the callback fires for *every* <iframe> on the
page (history, nocache/cache, etc ... each app) ... but the callback
receives a WebView and WebFrame object (diff frame each time), so it's
possible to discern what's what.
... isn't the SetDocumentLoadedCallback a custom function you've
added? my gut tells me something is messed up there. it seems more
stable to get a handle to the underlying WebView object and
.connect('onload-event'), or better, the main WebFrame object. per
the docs, there is one WebFrame for each URI.
may also be related to this:
"Some versions of WebKitGTK+ emitted this signal for the default error
page, while loading it. This behavior was considered bad, because it
was essentially exposing an implementation detail. From 1.1.19 onwards
this signal is no longer emitted for the default error pages"
... for the load-status property though; i'm not sure what
SetDocumentLoadedCallback is actually connecting to internally. sooo,
i think it's fixable, we just need to monitor the main frame directly,
and not the view (which appears to recieve events for all frames).
--
C Anthony
