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

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

On Tuesday 05 March 2002 17:01, Holger Freyther wrote:
> I'm for your initial API changes. Their much cleaner and you can find out if a 
> part supports streaming without .desktop adjustments. If openStream() fails 
> you know for sure a part doesn't support it.

Good thinking! I thought a .desktop file flag was needed anyway, so that we
directly find from the trader which part could support streaming for the datatype
we have, but your remark below proves this wrong:

> Another thought is what happends if a part supports say two different types of 
> data. For one it supports streaming and for the other not.
> Wouldn't a virtual bool openStream( const QString &mimeType = QString::null ){ 
> return false; ); better?

Yes, that sounds quite good. Although at the moment I don't know any part
that supports progressive loading for only some of the types it shows, that
flexibility will most probably be needed.

Compared to the internal IO slave, I like the idea of the virtual methods because
they're much more straightforward. Less "hidden magic" involved.

Waldo: ok if I commit those virtual methods ?

-- 
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]