[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KProcess and stdout/stderr!
From:       Tim Lee <tlee () tc ! fluke ! com>
Date:       2001-10-30 23:33:43
[Download RAW message or body]

On Tuesday 30 October 2001 04:58 pm, Waldo Bastian wrote:
> On Tuesday 30 October 2001 02:35 pm, Tim Lee wrote:
> > On Tuesday 30 October 2001 03:16 pm, Waldo Bastian wrote:
> > > On Tuesday 30 October 2001 12:20 pm, Tim Lee wrote:
> > > > On Monday 29 October 2001 06:44 pm, Waldo Bastian wrote:
> > > >
> > > > Thanks Waldo and others who have pointed me in correct
> > > > direction on this.  I ended up inheriting from KProcess
> > > > and using kdelibs/kdesu/kdesu_pty.h (libkdesu) to make
> > > > a KProcessPty that does all the IO through a terminal.
> > > > Seems to work well.
> > > >
> > > > Is anyone else interested in such a class?
> > >
> > > Might be a good candidate for kdecore, or maybe we can integrate it
> > > with KProcess and add a flag "use Pty" ?
> >
> > Seems cleaner as a subclass to KProcess since otherwise
> > it would require a lot of conditional code in KProcess.
> > The other option would be to break out a base class from
> > KProcess and have each inherit from it:
> >
> > 	KProcessBase
> >
> >   KProcess     KProcessTty
> >
> > KProcessBase would have all the KProcess stuff that
> > pertains to a process that is not stdin/stdout/stderr
> > (comm) related.  Currently my KProcessTty class is not
> > able to implement some of the KProcess features because
> > some of the methods are not virtual (suspend()/resume())
> > and the above would also fix that.
>
> Hm, there is also the slightly more convenient KProcIO class which
> currently dervices from KProcess, you don't want to end up with KProcIO and
> KProcIOTty.
>
> Unless you manage to move the KProcIO functionality into KProcessBase
> somehow.

Well, that just confuses things further, you are correct.
I'll have to look at KProcIO and see how it will fit into
the picture.  There is also KProcessShell but that could
easily be moved into a construction or start parameter.

>
> Cheers,
> Waldo
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

-- 
Tim Lee
R&D Design Engineer
Fluke Networks
6805 Corporate Drive, Suite 100
Colorado Springs, CO 80919
www.flukenetworks.com
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]