moin waldo, martijn, *,

as indicated in kdelibs/TODO, i'm planning some major rework of kprocess
for kde4.

1) anybody who tried redirecting a KProcess' i/o somewhere certainly
noticed that it is clumsy: either you have to override the *comm*
virtuals or you have to use setUseShell(true) to let the shell do the
redirection - or both. this is inconvenient and additionally sort of a
nightmare for the windows folks (right?). proposed api additions:

enum Direction { DefaultForFD, ReadOnly, WriteOnly, ReadWrite };
enum StdFDs { StdInFD = 0, StdOutFD = 1, StdErrFD = 2 };

// for open fds in the *parent* (this) process.
// this is the most generic one and works even on windows (at least for
// the first three handles without problems). in principle, everything
// else is only a convenience function.
KProcess::redirect( int handle, int sourceHandle, bool closeInParent = true );

// for files
KProcess::redirect( int handle, const QString& filename, Direction mode = DefaultForFD );

// piping processes is slightly more tricky. first variant:
KProcess::redirect( int handle, KProcess *drain, int drainHandle, bool bidirectional = false );
// however, the definition that this-> is the source is quite arbitrary.
// also, it is not clear how to control the pipe as a whole.
// so the second variant is a KProcessPipe class. simplest variant to
// build a pipe:
KProcessPipe::append( KProcess *process );
// the stdouts would be just piped into the followers' stdins.
// however, more complex structures might be possible, like chatting or
// piping each of stdout and stderr into another process:
KProcessPipe::add( KProcess *srcProcess, int srcHandle, KProcess *dstPprocess, int dstHandle, bool bidirectional = false );
// the pipe object keeps track of all involved processes. it offers a
// KProcess-like api that allows controlling them as if they were one
// process.
// adding KShell::buildPipeFromArgs() would make the setUseShell(true)
// case mostly superfluous even for user-entered commands.

strictly speaking, the current communication stuff in kprocess is a
special case of redirection as well. so it might make sense to transfer
all the i/o-related functionality into kprocio (and make the buffering
optional; it needs some rework anyway).
taking things to the extreme (that is, to the point where the common
case might become slightly inconvenient), one could introduce a
KProcessEndpoint class whose instances would be attached to particular
KProcesses to obtain the current std* stuff.
the opposite direction is merging KProcIO into KProcess to make it a
fully-integrated everything.
another possibility to consider is making KProcess (or the new KProcIO)
a multiplexed QIODevice, like QProcess is. not sure it is worth the
overhead, though - one can open a QFile with the process' fd at any
time. of course, having an integrated multiplexer reduces the number of
IODevice objects one has to manage at a given time.

of course i'm interested in martijn's input on how this all fits his
KExtProcess stuff, but from what i've seen it is mostly orthogonal.

a question to the windows folks: should i make the pre-/post-fork()
virtuals x11-only? afaik, fork() still needs to be emulated and is
horribly slow on windows, and i can't see how one could use fork() only
if needed (that is, if the virtuals are actually overridden).

2) multi-threading. currently all signals go into the event loop thread.
this sucks. not sure who should get them, though - the thread in which
the KProcess was created or the one it was started in?

3) well, nothing that needs discussion; see the TODO file. the prototype
will be open for discussion. :)

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.