On Tuesday 08 June 2004 00:35, Oswald Buddenhagen wrote:
> On Mon, Jun 07, 2004 at 06:57:19PM +0200, Peter Rockai (mornfall) wrote:
> > Another part of the same problem lies in the fact, that i need to be able
> > to do some custom post-fork initialization for KProcess. My proposed
> > solution would be to add a signal to KProcess, that would be emitted
> > right before the execvp call in KProcess::start (). This would allow to
> > do the required initialization in the child process, by connecting to the
> > signal.
>
> i think that's no good idea. derive from KProcess and reimplement
> CommSetupDoneC(). you may even make it emit a signal, but that would be
> an equally awful api as signal receivedStdout(int fd, int &len).
That is nice in theory, and i would gladly do that, if it was of some use. 
However, konsole is using TEPty class, which is derived from KProcess. So, 
without a delegation-based object model, which C++ has not, i can't make any 
real use of such a subclass, especially not from a client application. And 
TEPty is private to konsole, it is not exposed in any of the APIs.

Anyway, thanks for the comment. I will go with binary wrapper and some hacks, 
until i manage to fix the api in some way. But i believe this is unneccessary 
ugliness, and really should be fixed in the API. Any suggestions on solving 
this in an elegant way (i'm thinking about using functor to call back into 
user code, for example; but it's essentially the same as signal, just without 
its (not really wanted) multiple dispatch) would be appreciated.
>
> greetings
Yours,
    Peter