KProcess overhaul

Simon Hausmann hausmann at
Mon Oct 3 22:54:59 BST 2005

On Monday 03 October 2005 20:51, Oswald Buddenhagen wrote:
> On Sun, Oct 02, 2005 at 07:29:35PM +0200, Simon Hausmann wrote:
> > On Thursday 29 September 2005 20:36, Oswald Buddenhagen wrote:
> > > On Tue, Sep 27, 2005 at 11:23:54PM +0200, Martijn Klingens wrote:
> > > > [...] QProcess [...] is now a QIODevice that supports chaining.
> >
> > No methods indicate that :)
> >
> > [...] But the point about QIODevice was that it appears that the
> > QIODevice interface may be rich enough to create such chains of
> > objects, if for example each of these classes inherits from QIODevice,
> > had a reference to the next (QIO-)device, would connect to its signals
> > like readyRead and read and write data from/to it.
> you must be kidding ... you just suggested using the supervising program
> (our qt/kde app) as a proxy for potentially gigabytes of data (imagine a
> pipe from mkisofs to cdrecord, like in k3b).

No, that is not the use-case Martijn's KExtProcess classes try to address, to 
which my statements and the ssh example with QIODevice refer to. I see now 
that this is completely independent from the file descriptor redirection API 
that you're suggesting for KProcess.

> > What hooks are necessary for Pty support? Is it only providing two file
> > descriptors, one for use on the parent side (master fd) and one for use
> > in the forked/executed child (slave fd), for stdin/out/err, /plus/ a hook
> > that is called on the child side to set up the tty?
> on the "core process" side, pty support is just another special case of
> redirection.
> on the "endpoint" side, it is another type of pipe being created.
> here are the proposed api extensions for qprocess:
> // 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.
> // if endpointHandle is not -1, the io channel belonging to handle is
> // initialized with it. that means that the conceived KPtyProcess can
> // create a pty and force it onto the child process and QProcess' io
> // handling for selected channels.
> QProcess::redirect( int handle, int sourceHandle, bool closeInParent =
> true, int endpointHandle = -1 );

Thank you, I think I understand now what hooks are necessary so that a 
QProcess sub-class can implement Pty handling. I don't think such a generic 
redirection API is necessary for that specific task though.


More information about the kde-core-devel mailing list