KProcess overhaul

[Simon Hausmann]

On Thursday 29 September 2005 20:36, Oswald Buddenhagen wrote:
> On Tue, Sep 27, 2005 at 11:23:54PM +0200, Martijn Klingens wrote:
> > On Monday 26 September 2005 20:13, Oswald Buddenhagen wrote:
> > > enum Direction { DefaultForFD, ReadOnly, WriteOnly, ReadWrite };
> > > enum StdFDs { StdInFD = 0, StdOutFD = 1, StdErrFD = 2 };
> >
> > "DefaultForFD" doesn't really sound all that explanatory, although when
> > seen in the context of the API that uses it it passes the test -- barely.
> >
> > Furthermore this is the era of code completion,
>
> yeah - and 160 column views. ;)
> oh, and people can read faster meanwhile. ;)))
>
> > > // 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.
> >
> > (And the rest of the piping)
> >
> > From what I understood from Simon at aKademy QProcess got a major
> > overhaul and is now a QIODevice
>
> yes
>
> > that supports chaining.
>
> huh? which methods indicate such capability (whatever it might mean in
> that context ...)?

No methods indicate that :)

If I understand Martijn correctly with regards to process chaining then he for 
example wants to have a class that is capable of handling simple ssh or 
telnet authentication by looking for some magic tokens in the input, handles 
the authentication and afterwards just pipes input through to output. In fact 
I think he already has that code. 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.

The part where KProcess or QProcess come into play is at one end of the chain, 
where an object needs to sit that fires up a local process (ssh client, 
etc.).

So this chaining has nothing to do with KProcess vs. QProcess, it's about 
finding a good interface between objects in the chain. If QIODevice is good 
enough and you like the idea of making KProcess inherit from QIODevice both 
could be used at the end. But I'm not sure if such a flexibility buys 
anything.

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.

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.

> > When Simon,
> > me and Waldo looked into this during aKademy it seemed rather challenging
> > to do since the PTY support needs early hooks, but it seemed like the
> > Trolls were willing to at least consider the necessary glue.
>
> let's first design the api we consider optimal. if the trolls think
> they can do it all (or provide the hooks, at least), we can think
> about using qprocess as a basis (or exclusively). btw, the trolls are
> invited to participate in this discussion. ähm, actually, *anyone* -
> two days and only one minor comment from somebody not asked directly?
> hey, folks, we're talking about core components ...

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?

In any case I think Pty support is a feature that is nice to have in KDE, even 
if its unix specific. So a class that takes low-level KPty and combines it 
with a process class to a nice API makes sense IMHO. Whether that class uses 
KProcess or QProcess should be an implementation detail I would say :)


Simon