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 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. > Hm... not perfect possibly: for the ktexteditor preview plugin I plan in the future to also support restoring state, when switching preview between files or for app session restoring support. The kparts there are created not with "Browser/View" option, given the preview plugin does not support navigation. I'm not sure what's the relation. If you need any functionality from BrowserExtension, make sure it's created, I don't see how that means the app must "support navigation". > And for some reasons at least in my own kpart implementations (okteta, kmarkdownwebview) I assumed one would only create a BrowserExtension subclass instance if the part is created with "Browser/View" option? lxr.kde.org now shows me any other kpart implementation (at least kmplayer, kbibtex, dolphin, gwenview, okular) create the instance unconditionally. KHTML (which is a more interesting example because it shows original intent by the designers of KParts, rather than what other people might have interpreted later) also creates the extension unconditionally. After all, it's just a child object, it doesn't cost much to create it, even if the app will not make use of it. The servicetype Browser/View was more about selecting a different kxmlgui file. > So guess I should not be blinded by the name "BrowserExtension" and think it is only for browser/view usage, but instead think more of it as "extension, motivated by needs at least in browser but also elsewhere"? Yeah that's more like it. Originally the idea was KParts::ReadOnlyPart is as basic as possible, and extensions provide additional functionality, the browser being the first user, and other uses being free to require different extensions, but of course further thinking would have shown that extensions should be rather named after the functionality they provide than one specific use case. Other use cases can very well have the same needs, so one extension per use case is kind of stupid (code duplication). > 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. REPOSITORY R383 SVGPart REVISION DETAIL https://phabricator.kde.org/D7580 To: kossebau, #frameworks, dfaure
