[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-03 21:39:17
[Download RAW message or body]

On Sunday 03 March 2002 22:17, Martijn Klingens wrote:
> public:
>   bool openStream() { return doOpenStream(); }
>   bool writeStream( const QDataStream &s ) { return doWriteStream( s ); }

[Note: I meant QByteArray here. Whoops.]

>   bool closeStream() { return doCloseStream(); }
> private:
>   virtual bool doOpenStream() { return false; }
>   virtual bool doWriteStream( const QDataStream& ) { return false; }
>   virtual bool doCloseStream() { return false; }
> 
> With the function bodies of the public API specified in the cpp file and not 
> in the .h, so we can add code around it when needed in the future. Can't 
> think of a use yet, but for public API it might be worthwhile to think 
> broad...

Ok. At the moment I can't see either, what we would ever use this for, but the 
past has indeed taught us to never say never :)

> > 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.
> 
> I would still emit them though, because there might be components in the 
> hosting application that are completely agnostic on how the part is embedded. 
> After all the true power of signals and slots is that objects can be designed 
> mostly as black boxes that don't need to know about each other.

Yes, but the signals won't be listened to at all. Ok, then no docu, signals
remain unrelated to those methods.

> Maybe an additional signal dataAvailable() might make sense.
Huh? It's the hosting application that sends the data, it's not the part that loads it.
The part just displays the data sent to it.

> But I wouldn't 
> worry about signals! They can be added BC, so we can think about those after 
> KDE 3.0. Only the virtual methods need attention _now_ :-)
Sure, but thinking about the whole design is the only way to make sure
the virtual methods are okay ;)

Ellis: yes the return false in the header doesn't matter here. ReadOnlyPart is never
going to implement a concrete viewer itself! This is almost like pure virtual methods,
except that it's ok if parts are still "the old way", i.e. don't implement streaming.

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