QProcess vs K3Process

[Oswald Buddenhagen]

On Mon, May 28, 2007 at 03:34:32AM +0200, Andreas Pakulat wrote:
> I'd like to know wether its better to port KDevelop4 to QProcess usage
> now or stick with K3Process until KProcess (as a QProcess subclass) is
> available.
>
dunno. i could commit a basic KProcess today.

> It doesn't make much difference usage-wise, except that the K3Process
> way of setting the command and arguments is a bit more convienent.
> 
yes ... well ... really no big difference; you just have to make a
QStringList yourself.

this is a list of missing [KQ]Process features and differences between
qproc and k3proc. please comment on the desirability of the particular
points.

- qproc has no pty support. that's fine, it is doable in kproc. i guess
  i'll follow the advice to create a separate KPtyProcess class for it.
  together with KPty and KPtyDevice (QIODevice wrapper around KPty) it
  would move to kdelibs/libkpty.
  
- qproc does not allow setting individual env vars, only the entire
  environment. pretty inconvenient, if you ask me. can be easily
  implemented in kproc.

- qproc does not support setting priorities.
  win32 has only scheduling classes, while unix has (fewer) classes
  and the nice level. this needs some thinking.
  should be possible in kproc, but pretty ugly. (*)
  preparing mail to qt-bugs.

- as noted above, qproc' way of naming the program to execute is
  different and less convenient. "fixable" in kproc. (*)
  related ttt (trolltech task): 164361.
  
- qproc has no setUseShell. generally, shell usage should be eliminated
  as far as possible (usually it is used for constructing hard-coded
  pipes, for which qproc has a better solution now - for most parts).
  however, user-supplied commands might still need being run through a
  shell. big fat note: on win32, the shell would be cmd, i.e., not posix
  sh compatible except for the most trivial redirections. (*)

- qproc does not allow handling only one of stdout/stderr (ttt 131926).
  kproc could work around this by playing a proxy for the unhandled
  channel. that's Not Nice (performance, reliability), but qproc does
  this on win32 anyway (i have no idea why). when qprocess gains the
  feature, the kproc api would become a trivial wrapper.

- qproc by default handles stdout/stderr, while k3proc forwards it. imo,
  the k3proc' "do only what was requested"-approach is much saner, as it
  does not suppress (error) output (90% of the users *will* forget to
  disable the unneeded functions). this is "fixable" in kproc, but sort
  of ugly - i would not do it unless we "condemn" direct qproc usage.

- qproc' startDetached() and execute() are statics.
  parametrization-wise, this doesn't scale at all. execute() is no
  problem, as it is trivial. startDetached() *is* a problem - and not
  fixable in kproc. ttt 131923.

- qproc has no detach(). not fixable in kproc. ttt 131933.
  there is exactly one user in kdelibs: kio/kfile/kfilesharedialog.cpp.
  please verify that it is legitimate, i.e. that the child must be able
  to outlive the parent and that it cannot be started detached in the
  first place. hi dfaure ;)

- qproc cannot join the (output) channels of multiple processes. not
  fixable in kproc. ttt 131901.
  this is from the "get rid of setUseShell" camp. not critical.

- qproc does not support process groups/jobs.
  also from the "get rid of setUseShell" camp. primarily meant as a
  convenience feature - it sucks to build a pipe from three processes
  and having to deal with every one separately. this can be built as a
  separate class KProcessGroup; the os-level part which is not fixable
  in kproc is sort of optional. mail to qt-bugs in preparation.

- anything i forgot?

(*) to implement this, start() needs to be overridden. as it is not
virtual, any function that is expected to start a process itself would
need an actual kproc *, not qproc *. i don't expect this to be a problem in
practice, as apis that take processes are generally sort of rare.

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