From kde-core-devel  Thu Sep 29 18:36:32 2005
From: Oswald Buddenhagen <oswald.buddenhagen () technik-akademie ! de>
Date: Thu, 29 Sep 2005 18:36:32 +0000
To: kde-core-devel
Subject: Re: KProcess overhaul
Message-Id: <20050929183632.GA10704 () r5024-01 ! technik-akademie ! de>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112801908730449

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

> Thus it supports piping as well.

> How difficult would it be to port KProcess to QProcess
>
the old kprocess is inherentily qprocess-incompatible. fwiw, at
kastle, i talked with matthias about folding back kprocess parts 
into qprocess.
qprocess as it is now is incompatible with my kprocess plans as well,
afaics.

> or at least give it a compatible API?
>
maybe. that's part of this RFC, sort of.

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

> > 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.
> 
> I'm not sure this is clear to me without taking a deeper look into QIODevice 
> and QProcess. I'm afraid it does answer my above question though, which is 
> kinda annoying :/
>
qprocess multiplexes stdout and stderr into the reading channel of the
io device and you have additonal selector functions to switch the
source.