[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Question about behavior of history navigation in restored konqueror
From:       Dawit A <adawit () kde ! org>
Date:       2010-08-25 15:42:49
Message-ID: AANLkTikvLdKhRzXPHdBk09Aed9bpnSUj2rWgH0hGaSdM () mail ! gmail ! com
[Download RAW message or body]

Hello,

I have a question about Konqueror's method history restoration after
abnormal termination. Specifically I am trying to understand the purpose of
HistoryEntry's reload flag which prevents a part's restoreState function
from being invoked if history navigation was restored say after a crash.
This flag was introduced with commit -r873000 in konqview.cpp.

After that commit only the history state for last url visited will be
properly restored fully. All other restored history item s will have their
"reload" flag set to false when they are reloaded in HistoryEntry::loadItem
(konqview.cpp). That in turn will ensure that the embedded part's
"restoreState" function is never invoked when the user starts navigating
back and forth through history items (see line #811).

As such, history navigation will behave completely differently on
restored Konqueror session than a normally started one. In normally started
Konqueror instances, history navigation will always call restoreState(...)
where as in restored instances that function is only called for the first
item restored. Afterwards all history navigation will end up calling
openUrl(...) as if the user entered a new url into the location bar.

My question the is, was this done intentionally ? If so why ? To speed
up restoration as seems to be indicated from the commit log of r873000 ?

Regards,
Dawit A.

[Attachment #3 (text/html)]

<div>Hello,</div><div><br></div><div>I have a question about Konqueror&#39;=
s method history restoration after abnormal=A0termination. Specifically I a=
m trying to understand the purpose of HistoryEntry&#39;s=A0reload flag whic=
h prevents a part&#39;s restoreState function from being invoked if=A0histo=
ry navigation was restored say after a crash. This flag was introduced with=
=A0commit -r873000 in konqview.cpp.</div>
<div><br></div><div>After that commit only the history state for last url v=
isited will be properly=A0restored fully. All other restored history item s=
 will have their &quot;reload&quot; flag=A0set to false when they are reloa=
ded in HistoryEntry::loadItem (konqview.cpp).=A0That in turn will ensure th=
at the embedded part&#39;s &quot;restoreState&quot; function is=A0never inv=
oked when the user starts navigating back and forth through history=A0items=
 (see line #811).</div>
<div><br></div><div>As such, history navigation will behave completely diff=
erently on restored=A0Konqueror session than a normally started one. In nor=
mally started Konqueror=A0instances, history navigation will always call re=
storeState(...) where as in=A0restored instances that function is only call=
ed for the first item restored.=A0Afterwards all history navigation will en=
d up calling openUrl(...) as if the=A0user entered a new url into the locat=
ion bar.</div>
<div><br></div><div>My question the is, was this done intentionally ? If so=
 why ? To speed up=A0restoration as seems to be indicated from the commit l=
og of r873000 ?</div><div><br></div><div>Regards,</div><div>Dawit A.</div>
<div><div><br></div></div>


[prev in list] [next in list] [prev in thread] [next in thread]