[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:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2002-03-03 21:17:53
[Download RAW message or body]

On Sunday 03 March 2002 21:49, David Faure wrote:
> [ ... ]

I don't think I have to explicitly express my approval here, that should be 
clear :-)

I do have some thoughts about it, though that I came up with just after David 
moved our private discussion to kde-core-devel.

Would it be a good idea to use the Template Method pattern instead that Dawit 
mentioned on kde-cvs last week? That might be even more flexible. What the 
API would be like then is

public:
  bool openStream() { return doOpenStream(); }
  bool writeStream( const QDataStream &s ) { return doWriteStream( s ); }
  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...

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

Maybe an additional signal dataAvailable() might make sense. 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_ :-)

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