On Fri, Feb 3, 2012 at 6:48 PM, C Anthony Risinger <[email protected]> wrote:
> 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
> ...
good man.
> 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.
frack. of course! you're a sodding genius, you are.
> 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.
haaaaaaaa
> ... 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.
forget webkitgtk.
> 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).
superb. now i know what to look for i can deal with that.
HA! :)
it's probably the same for the other jobbies too.
