This revision was automatically updated to reflect the committed changes.
Closed by commit R383:d1ee5a0e3908: Support loading by stream and restoring
state on reload (authored by kossebau).
REPOSITORY
R383 SVGPart
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D7580?vs=19446=19814
kossebau edited the summary of this revision.
kossebau edited the test plan for this revision.
REPOSITORY
R383 SVGPart
BRANCH
supportstreamandreload
REVISION DETAIL
https://phabricator.kde.org/D7580
To: kossebau, #frameworks, dfaure
kossebau added a comment.
Thanks for quick reaction :) Will push now, even if we discovered another
item which needs some more clarification. Would do a follow-up fix then if we
find one is needed,
INLINE COMMENTS
> dfaure wrote in svgpart.cpp:191
> When I reload in konqueror (with KHTML
dfaure accepted this revision.
dfaure added inline comments.
This revision is now accepted and ready to land.
INLINE COMMENTS
> svgpart.cpp:191
> +// we can't tell if caller has explicitely set xOffset/yOffset of
> OpenUrlArguments
> +// so in case of same url we just assume a reload
kossebau added a comment.
In https://phabricator.kde.org/D7580#145144, @kossebau wrote:
> With the latest update then this patch would represent the blue-print for
KParts plugins as I see it when it comes to supporting both state restoring and
support for streams, at least for what is
kossebau added a comment.
In https://phabricator.kde.org/D7580#144557, @dfaure wrote:
> In https://phabricator.kde.org/D7580#144518, @kossebau wrote:
>
> > When I read this initially, I guessed this method is just about the view
state. But is also bound to data-pulling by the kpart,
kossebau updated this revision to Diff 19446.
kossebau added a comment.
add support for state restoring via BrowserExtension
REPOSITORY
R383 SVGPart
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D7580?vs=19091=19446
BRANCH
supportstreamandreload
REVISION DETAIL
dfaure added a comment.
In https://phabricator.kde.org/D7580#144518, @kossebau wrote:
> When I read this initially, I guessed this method is just about the view
state. But is also bound to data-pulling by the kpart, given that the default
implementation explicitely calls openUrl() with
dfaure added a comment.
In https://phabricator.kde.org/D7580#142971, @kossebau wrote:
> > "how would zoom and other custom state properties be save and retrieved
again" -> using BrowserExtension's saveState/restoreState as usual, no? I'm
not 100% sure about the interaction with
dfaure added a comment.
Oops, yes, you're completely right. I got distracted by the word close, but
it's a different meaning in closeStream and closeUrl. Apologies for the
confusion.
As to existing implementations of this stuff, it just happens that I wrote
one recently, see
kossebau edited the summary of this revision.
REPOSITORY
R383 SVGPart
REVISION DETAIL
https://phabricator.kde.org/D7580
To: kossebau, #frameworks, dfaure
kossebau added a comment.
> As I see it, it's *either* openUrl/closeUrl *or*
openStream/writeStream/closeStream.
Hm, when I before did a quick search for how to use the stream API, I came
across
https://api.kde.org/frameworks/khtml/html/classKHTMLPart.html#details
which made me
dfaure added inline comments.
INLINE COMMENTS
> svgpart.cpp:118
> +mStreamedData.clear();
> +mItem = new QGraphicsSvgItem();
> +mItem->setSharedRenderer(mRenderer);
Shouldn't mItem be deleted first?
You seem to rely on closeUrl() being called before the next openStream, but I
don't
kossebau updated this revision to Diff 19091.
kossebau added a comment.
handle repeated closeUrl call
REPOSITORY
R383 SVGPart
CHANGES SINCE LAST UPDATE
https://phabricator.kde.org/D7580?vs=18868=19091
BRANCH
supportstreamandreload
REVISION DETAIL
https://phabricator.kde.org/D7580
kossebau created this revision.
REVISION SUMMARY
The KTextEditor preview plugin* repeatedly feeds new
versions to the same kpart instance, to allow instant
preview of changes. To avoid stressing of the filesystem
the stream API of the kpart is used if available.
15 matches
Mail list logo
