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

List:       kde-core-devel
Subject:    KParts API: thinking about the future (patch)
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-03-03 20:49:52
[Download RAW message or body]

The current API of KParts::ReadOnlyPart is centered around "open a URL,
emit signals while doing it, and display it".
What would be needed in some cases, though, would be to be able to
send data to a part, from the "outside", without a URL available.
One could call that "streaming": having a way to load data in any way,
not restricted to ioslaves, and send it progressively to the part so that it
can display it.

One example is the kmultipart stuff I put in kdenonbeta ("server push" support),
it currently only supports HTML because only khtml has begin/write/end
for sending data to it.

Other examples could be.. using a text editor component to pipe a log
file to it (never-ending stream, unlike a direct openURL of that file),
and maybe more advanced stuff later (movies?).

Martijn Klingens reminded me that we discussed about this at the FOSDEM,
and that the simplest solution would be 3 new virtual methods to ReadOnlyPart,
following khtml's begin/write/end API. Here's what I would want to add
to ReadOnlyPart, with no other implementation nor use of this yet, just
a 'hook' for after 3.0:

/**
 * Initiate sending data to this part. 
 * This is an alternative to openURL, which allows the user of the part
 * to load the data itself, and send it progressively to the part.
 * @return true if the part supports progressive loading and accepts data, false otherwise.
 */
virtual bool openStream() { return false; }
/**
 * Send some data to the part. @ref openStream must have been called previously,
 * and must have returned true.
 * In this method the part should attempt to display the data progressively.
 * With some data types (text, html...) @ref closeStream might never actually be called,
 * in the case of continous streams. This can't happen with e.g. images.
 */
virtual bool writeStream( const QDataStream& ) { return false; }
/**
 * Terminate the sending of data to the part.
 * Parts should ensure that all of the data is displayed at this point.
 */
virtual bool closeStream() { return false; }


This is quite straightforward, it will be very easy to port at least
khtml, kview, and katepart to it (which ones do I forget?)

I'm not sure about signals... ReadOnlyPart has the signals started(), 
completed() and canceled(), but in this case, since the hosting application
has complete control, I don't see how the signals would be useful.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

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