kossebau added a comment.
In https://phabricator.kde.org/D7580#144414, @dfaure wrote: > 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 streaming, but normally that happens after opening the url anyway, so it should be unrelated. > > > > Oh, somehow missed those methods. Possibly was blinded by KParts::OpenUrlArguments::xOffset()/yOffset() and since then assumed that state restoring was supposed to be done only via those arguments. > > > That's just the default implementation of BE::restoreState(), which loads url+offsets and calls setArguments before openUrl. But this is virtual, so more can be done. Okay, matches the picture I have got meanwhile once I read more through the API dox and code (history) of Konqeror, KHTML and KParts. Though sadly there is a bummer with void BrowserExtension::restoreState(QDataStream& stream) <https://api.kde.org/frameworks/kparts/html/classKParts_1_1BrowserExtension.html#aa079a1969335549d2c20a3ce60ce4dfa>: Used by the browser to restore the view in the state it was when we left it. If you saved additional properties, reimplement it but don't forget to call the parent method (probably first). 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 the url stored in the datastream. Which might make sense for simple-to-use API with the non-stream use cases. But leaves out the stream-based data-pushing usage. Seems I have to sit down and draft some generic stream usage test cases and derive from that some proposal for a KParts API extension of some kind. No resources for that right now, might only do later this year. So no session support or view state memory in the KTextEditor Preview plugin then for now, too bad, would have been nice to have. >> And only enable/activate the browser-integration specific parts if the part is created with "Browser/View"? > > No, I wouldn't recommend that. Create the extension always, let the app decide whether to use it. Okay, thanks for clarification. Will complete this patch next to at least support classic browser view state restoring as via BE::restoreState(). BTW: can you tell if Falkon will/does support kparts? REPOSITORY R383 SVGPart REVISION DETAIL https://phabricator.kde.org/D7580 To: kossebau, #frameworks, dfaure
