KProcess overhaul

[Martijn Klingens]

Hi Ossi,

Some remarks, but the hardcore technical details, especially on other 
platforms, are really not my territory. So bear with me if I start asking 
stupid questions...

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, so I see no convincing reason 
to call it FD instead of FileDescriptor. Std{In,Out,Err} is a bit of a legacy 
from 1970s Unix and the C library, so that one can stay. Perhaps additional 
entries Standard{In,Out,Error} with the same values might not even hurt 
though. /me looks at API gurus like Simon...

> // 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 that supports chaining. Thus it supports piping as well.

How difficult would it be to port KProcess to QProcess or at least give it a 
compatible API? The old KProcess can stay as K3Process if needed. 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.

> 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 :/

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

After the before-mentioned talks with Simon I think I'll give KExtendedProcess 
a QProcess-like API, or ideally use a true QProcess subclass. That means I'll 
be moving away from KProcess, but QProcess seemed the nicer API at first 
glance, and if it remains my API of choice on second thought I'd personally 
push people into porting KProcess to QProcess for KDE 4.

Lots of ifs, but don't worry about my code all that much. Even if I stay with 
KProcess-as-it-is-now it's mostly orthogonal indeed. What might work is 
sharing the namespaces and or enums. What is also worth considering in that 
scenario is pulling KProcess into KExtendedProcess::LocalProcess, make that 
the preferred class and provide KProcess only as a convenience typedef. That 
would basically turn all apps into extprocess consumers for free, so only the 
GUI portion for cross-system execution would be needed. The overhead of 
LocalProcess can be removed if KProcess is the same class, so apart from some 
extra symbols and three variable initializations in the base class there is 
none.

Having said that, with my recent activities for KDE NL and the working groups 
I somewhat doubt I'll be able to continue KEP development anytime soon, which 
essentially will make it slip the KDE 4 timeframe. And I see no real solution 
to that :/ (apart from winning the lottery, quitting my job and working 
fulltime on KDE)

-- 
Martijn