kprocess, kpty & kdesu

Oswald Buddenhagen ossi at
Wed May 2 22:07:18 BST 2007

On Wed, May 02, 2007 at 09:56:19PM +0200, Simon Hausmann wrote:
> On Wednesday 02 May 2007 21:12:04 Oswald Buddenhagen wrote:
> > 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
you mean, except of pty support itself? ;)
none somebody seriously considered a separate class for, afaik.

> and based on that how many features do you think we're going to *need*
> in the future for controlling processes using file descriptors
nobody said the new features need to be related to the io channels.

> 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.
oh, yeah, right. /QProcess/d

> When are we going to be able to talk to kdm or gdm using the system
> bus? :)
i've been thinking about that since before n7y. like about many other
Really Cool Things (TM). :)

> > > 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
uhm, so what? that the two known use cases that already have
implementations are platform specific does not mean that others are not
probable. if foo.dll gives me a handle to COM, i'd sure prefer to talk
to it via a qiodevice than via posix calls. well, maybe not me, but most
other qt & kde devels, i figure, otherwise q*socket* would be a pretty
simple collection of #defines. ;)

> > - 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 doesn't seem
> to bring up a whole lot of use-cases that ask for a generic
> KSequentialDevice :)
hmm? this doesn't make any sense. look for setUsePty and then think
about how using bare kpty (that is, even less than old kprocess offers)
with qprocess would look like.

> > it is pretty much conceivable that other sequential devices want to
> > be wrapped, too. [...} 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
do you want more quality or more quantity? more quality is impossible,
as this is the perfect example. more quantity will come all by itself
once the class is there - this is really basic functionality, and that
happens to be used a lot - be it with or without nice qt abstractions
(remember our discussion about qprocess redirections?).

> with a pretty prominent name (KSequentialDevice).
make it KNonProminentSequentialDevice.

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

More information about the kde-core-devel mailing list