kprocess, kpty & kdesu

[Simon Hausmann]

On Wednesday 02 May 2007 21:12:04 Oswald Buddenhagen wrote:
> On Wed, May 02, 2007 at 08:40:35PM +0200, Simon Hausmann wrote:
> > Providing a PTY implementation surely is useful for some unportable
> > applications, but I'm not sure it is worth the prominent KProcess name.
>
> this question was asked even before windows came into the game. :)
> suppose another specialized kprocess derivative is introduced. and then
> you suddenly realize you need features from both, simultaneously. whoops.

KProcess was one of the very early KDE 1 library classes, right? How many 
special features or special derivaties have you seen in the last ten years of 
KDE development and based on that how many features do you think we're going 
to *need* in the future for controlling processes using file descriptors in 
the evolving world of the POSIX API? :)

The notion of a Uniux process in our desktop environment seems to disappear to 
me in favor of DBus/DCOP services for example. When are we going to be able 
to talk to kdm or gdm using the system bus? :)

> > Would KSequentialDevice solve a particular problem or is it just a
> > because-we-can class? :)
>
> i hoped my reasoning would be obvious. ;)

You have mentioned kwrited and kdm as example applications, both of which are 
not portable and both would be fine with just KPty, no? :)

Ah yes, kprocess was the other example, but I still maintain that ptys are an 
exotic unportable feature :) (a cool one nevertheless).

> - an equivalent of this class is needed for adding ptys to kprocess in a
>   qprocess-like way.

Again, who uses this? Searching for "KPty" on lxr.kde.org doesn't seem to 
bring up a whole lot of use-cases that ask for a generic KSequentialDevice :)

> - making kpty a qiodevice would be nice anyway (the two direct users use
>   it via posix functions now).
> - it is pretty much conceivable that other sequential devices want to be
>   wrapped, too (i'm pretty sure i'd find some examples if i scanned the
>   kde codebase (*)). so why not go for a generic solution?
>
> (*) i know from experience that this is a non-seller for the trolls. ;)
> anyway, i'm right with my "predictions", yet another time: in fact, the
> same function in kdm that uses the pty uses a char device as an
> alternative. q.e.d. :=)

Your one kdm example doesn't convince me at least for a generic solution with 
a pretty prominent name (KSequentialDevice).


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/b548c9cb/attachment.sig>