kprocess, kpty & kdesu

[Oswald Buddenhagen]

moin,

some more or less chaotic facts & thoughts:

- kdesu duplicates a lot of kpty & kprocess. i started a patch to rip
  it out and migrate the users a year ago, but did not finish because
  nothing worked (even without my patch ;) and i had no time.

- kprocess would extend qprocess and provide:

  - pty integration on unix. it is used by konsole, ark and kpackage and
    potentially by kdesu, kdepasswd, cervisia, kio_sftp and
    konq/shellcmdplugin (current kdesu/PtyProcess users).
    
    the integration will never be perfect (e.g., there is simply no way
    to get the pty supported by the waitFor* functions), but i think we
    can get quite close (set{Read,Write}Channel for read()/write(),
    setup, notfications, etc.)

  - cover up qt's omissions, at least on unix. particularly, the
    possibility to manage only stdout and leave stderr alone (that is,
    in .xsession-errors for most times).
    
    hopefully this will be finally implemented in qt 4.4, so the
    kprocess api would turn into a simple wrapper.

  - possibly adjust i/o channel defaults to be like k3process: request
    what you want, not what you don't want. this is particularly
    interesting for the above stderr case, as i bet almost nobody will 
    think about it.

  - we might want to keep kprocio's charset conversion

- kpty is unix-only. as it stands now, it is just a nice wrapper around
  creating a pty. kpty has only two direct users: kwrited and a function
  in kdm that is compiled only on suse systems by default (afaik). and
  then it is used by kprocess, of course.

  i had some thoughts about turning kpty into a qiodevice. in some way
  this is needed for the kprocess integration.
  on the downside, k3process would need some api to get to the bare pty
  as it is now. ugly ...
  then i thought about creating KPtyDevice. it cannot do multiple
  inheritance (from QIODevice and KPty), so it'd have to own the pty -
  no big deal (how does process->ptyDev()->pty()->setUtf8(true) look to
  you? :}).
  then i had yet another idea: why restrict it to ptys? i think we could
  create KSequentialDevice which would be able to act as an end point
  for arbitrary character devices, pipes/fifos and stream sockets. this
  might be useful when one gets a file descriptor from a library (like
  from kdecore/kpty :) one wants to work with (e.g., in kprocess :).

freeze-wise this should be uncritical, as it doesn't really affect
anybody who is not interested - util the final move of k3* to
kde3support after kdelibs itself was migrated. and you must admit it
would be greatly uncool not to get this done. ;)

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