KProcess overhaul

[Oswald Buddenhagen]

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

> One would think that QIODevice as interface would allow things like putting a 
> QFile at the beginning of the chain, but I realize that's not possible, as of 
> course QFile has no idea about 'writing' into the next device in the chain. 
> And if the order is reversed, that is each object in the chain knows about 
> the input device then QProcess could not be put at the end of the chain.
> 
again the same mistake.

point is, q/kprocess doesn't need to do anything once the redirection is
established.
that's also the reason why i suggested splitting the
supervisor-is-endpoint (kprocio/qiodevice) case from the core kprocess.

> On the other hand having a process class that inherits from QIODevice has 
> advantages such as being usable in the Qt API where a QIODevice can be 
> specified, for example in QXmlReader as input source, or 
> QPicture/QImage/QMovie or KZip/KTar.
> 
i think everybody is aware of these advantages. following the strict
split idea, maybe make only kprocio a qiodevice. however, then we'd need
kprocio to inherit from both qiodevice and kprocess (impossible,
obviously) or not be a kprocess itself - not sure if that would pose a
major problem.

> 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 );

// overload for files
// note that this function can be implemented using the generic
// redirect, but on unix it is more efficient to open the handles in the
// child process only.
QProcess::redirect( int handle, const QByteArray& filename, Direction mode = DefaultForFD );

// overload for those who loathe plain file names. i consider it
// superfluous. ;)
QProcess::redirect( int handle, const QFile& file, Direction mode = DefaultForFD );

// overload for those who loathe file handles. i consider it
// superfluous. ;)
// the api is confusing. tell me why. ;)
QProcess::redirect( int handle, QIODevice& file, bool closeInParent);

these functions would have to be called by the start() of the inheriting
class - making start() virtual or adding virtual setupRedirects() would
be cool - too cool for BC.

regarding building process pipes, just take the KProcessPipe api ideas
verbatim.

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