kprocess, kpty & kdesu

[Oswald Buddenhagen]

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 lxr.kde.org 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.