ExtTerminalInterface + KProcess extension for KDE 3.4/4.0
Peter Rockai (mornfall)
mornfall at danill.sk
Tue Jun 8 00:37:01 BST 2004
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.
More information about the kde-core-devel