kprocess, kpty & kdesu

[Simon Hausmann]

On Monday 30 April 2007 22:02:43 Oswald Buddenhagen wrote:
> 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

If we say that applications /must/ use the K* variant of a class over a Q* one 
(according to the proposed krazy check) then I have to say I don't really 
like the idea of KProcess extending QProcess with unportable Unix-only 
features. I would be /particularly/ hesitant about the pty support for 
Windows since I haven't seen any successful re-implementation of the win32 
console subsystem so far (unless somebody manages to rip out the hidden 
window in console). A colleague of mine told me many horror stories of his 
attempts to write a konsole equivalent on Windows and the constant problems 
of fighting with the deep integration of cmd.exe.

Providing a PTY implementation surely is useful for some unportable 
applications, but I'm not sure it is worth the prominent KProcess name. 
Especially given that the QProcess API cannot be fully supported I wonder if 
it wouldn't be better to have this functionalty in a class with a different 
name.

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

Would KSequentialDevice solve a particular problem or is it just a 
because-we-can class? :)


Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070502/a146d36a/attachment.sig>