[Kde-windows] KProcess overhaul

[Ralf Habacker]

Oswald Buddenhagen schrieb:
> On Sat, Apr 15, 2006 at 10:50:14AM +0200, Ralf Habacker wrote:
>   
>> for windows the recent KProcess implementation is unusable, so I'm going 
>> to provide an initial KProcess implementation with the following steps:
>>
>>     
> feel free to do so, but be prepared that qt 4.2 will make at least some
> of your work be in vain, and you will be told by some kde code dev
> employed by tt "why maintain code in kde if we can offload it to tt?".
> of course it is just a minor detail that i'm waiting for solid 4 months
> to get even a *remote* specification of what is planned.
>
>   
>>   5. The results of the studies are
>>         2. QProcess will probably be able to deal with KDE specific
>>            forking and pty needs because there is are protected hooks:
>>               1. setupChildProcess -  This function is called in the
>>               child process context just before the program is
>>               executed on Unix or Mac OS X (i.e., after \e fork(), but
>>               before \e execve()). Reimplement this function to do
>>               last minute initialization of the child process.  but
>>               this have to be confirmed by some unix gurus.
>>
>>     
> that's too little. i mean, we *could* build it on top of it, but it
> would be utterly ugly.
>
>   
>>         3. io redirection will be able because qProcess returns the
>>            data in memory, which could then be redirected to anywhere
>>
>>     
> that's an argumentation i heard from tt as well. to make it absolutely
> clear: using the parent process (that is, the QProcess) as a proxy is
> *no option*:
> - resource usage (double copy)
> - dependency of a forked pipe (multiple connected child processes) on
>   the parent:
>   - latency, up to reliability problems
>   - no way to exit the parent and let the children live on
>   
Also after rereading the thread "KProcess overhaul", you have started 
I'm not sure, what you exactly means with this. Seems we have to collect 
the requirement for the planned KProcess. I mean KProcess should have 
the following functionality or speeking in use cases:

1. it should be able to start child process in blocking an non blocking 
mode
2. it should be possible to provide the child process with specific  
command line arguments and a specific environment
3. it should be able to set the working directory of the started child 
process
4. it should be able to send data to the child process stdin
5. it should be able to get data from the child process stdout and stderr
6. it should be able to terminate child processes
7. it should be able to get a signal on child process termination

all of the above mentioned features are possible with recent QProcess.

Do you have more required features ?

>> 7. My plans are
>>         2. To implement required functions/features in an iterating way
>>            to avoid to much headage about thinking what may be required
>>            and what not to early.
>>
>>     
> that way you easily end up with a mess. you should at least have an idea
> of the Big Picture.
>   
I' m based currently on QProcess, which fit all my needs.
>   
>> Things to discuss by the KProcess gurus:
>>    1. Should KProcess include QProcess public, protected or in 
>> KProcessPrivate ?
>>
>>     
> public is fine, i guess.
>
>   
>>    2. Who will implement the unix and mac related parts ?
>>
>>     
> me for unix, but not before tt makes up and reveals its plans.
>
>   
>>    3. Who will write the doc ? (I'm currently not very familar with KDE 
>> doc writing, I can write examples as shown  below)
>>
>>     
> doc? hääää?!? are you stoned?!??!? :)))
>   
No ? Isn't any doc/examples required for this new class ? At least the 
inline documentation has to be written because it will have a different 
api than K3Process.
>   
>> now it is real requred to fix this stuff, because the next major
>> windows KDE issue - kdeinit and kioslave loading are waiting for a
>> solution.
>>
>>     
> yeah - tell tt.
>   
over which communication channel ?
> to sum it up, i think you can do the following without potentially
> wasting work:
> - move kprocess/kprocio to kde3support
>   
what about KProcessController, K3Process requires it and KApplication 
also, so kde3support have to be included by kdecore.

> - create class KProcess : public QProcess and implement everything you
>   need that can be *cleanly* implemented on top of existing
>   functionality - 
there is nothing else required for windows at now.
> i think it is reasonable to assume that our api will
>   be qprocess-like, even if we find ourselves forced to reimplement it
>   from scratch. not that i like every detail of that api, but i guess it
>   makes sense for the sake of consistency - at least as long as our
>   extensions can be done without them looking bolted on.
>
>   
Ralf