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 think the closeStream is more in the idea of QIODevice::close, to hint that there is no further data coming in. The API dox of ReadOnlyPart enforced that idea with me: - ReadOnlyPart::closeStream() <https://api.kde.org/frameworks/kparts/html/classKParts_1_1ReadOnlyPart.html#aa828fc225a2f32563624053f80f40257>: "Terminate the sending of data to the part." - ReadOnlyPart::doCloseStream() <https://api.kde.org/frameworks/kparts/html/classKParts_1_1ReadOnlyPart.html#a7c7633244f0419124ca52224379d4743>: "This is called by closeStream(), to indicate that all the data has been sent. Parts should ensure that all of the data is displayed at this point." And with that in mind the existing ReadOnlyPart code matched my expectations, as `ReadOnlyPart::openStream`calls closeUrl, similar to how `ReadOnlyPart::openUrl` calls it. So openUrl would be only matched by openStream/writeStream/closeStream, with the latter triple being the push variant to the first. And closeUrl would be used with both, to tell the part to unload the current content, disconnect from the content source if needed and display some void, with the url being reset to invalid/none. So the whole purpose of closeStream would be to just signal that no more data will come in, so e.g. any "loading more" indicator can be hidden. I now found the original discussion thread for the stream API (KParts API: thinking about the future... <http://markmail.org/message/vn2wu7r3mowf2gya>, just 15 years old :) ) which does not shed that much more light onto the idea of the API, though I could read into it my existing understanding of the API :) But that's why I included you @dfaure into this review, as there is no current implementation/usage of the API, so chance I just see what I need here :) And hope you(r memories) could correct me were wrong. Though now I see your initial memories conflicting with the API dox & code? Meh... REPOSITORY R383 SVGPart REVISION DETAIL https://phabricator.kde.org/D7580 To: kossebau, #frameworks, dfaure
