[Kde-windows] KProcess overhaul
Ralf Habacker
ralf.habacker at freenet.de
Sat Apr 15 10:50:14 CEST 2006
Hi all,
for windows the recent KProcess implementation is unusable, so I'm going
to provide an initial KProcess implementation with the following steps:
1. recent KProcess and KProcio classes will be renamed to K3Process
and K3Procio and moved to kde3support
2. KProcess will be a subclass of QProcess (public), which could be
extended with the special KDE needs
3. My focus and my knowledge in mainly limited to windows, so I'm not
able to make a design for all platforms KDE runs on.
4. I have studied QProcess, the kde sources and the kde-core-devel
mailing list for relating topics (especial the one at
http://lists.kde.org/?l=kde-core-devel&m=112775845325713&w=2)
5. The results of the studies are
1. QProcess will be able to handle the requirements I see in
the KDE sources at least for windows.
2. QProcess will probably be able to deal with KDE specific
forking and pty needs because there is are protected hooks:
1. setupChildProcess - This function is called in the
child process context just before the
program is executed on Unix or Mac OS X (i.e.,
after \e fork(), but before
\e execve()). Reimplement this function to do last
minute initialization
of the child process.
but this have to be confirmed by some unix gurus.
3. io redirection will be able because qProcess returns the
data in memory, which could then be redirected to anywhere
4. using a shell must be implemented separatly may be by
another KProcess function
6. The initial implementation derives QProcess public, that means
that KProcess will be QProcess
(This may be changed in the future to overwrite some QProcess
provided functions with same signature but extended functionality.
I think there are enough KDE gurus who can decide this better than I)
7. My plans are
1. to uses available code as much as possible and not to
reinvent the wheel.
2. To implement required functions/features in an iterating way
to avoid to much headage about thinking what may be required
and what not to early.
Things to discuss by the KProcess gurus:
1. Should KProcess include QProcess public, protected or in
KProcessPrivate ?
2. Who will implement the unix and mac related parts ?
3. Who will write the doc ? (I'm currently not very familar with KDE
doc writing, I can write examples as shown below)
Because I'm a friend of designing api's by examples here are some examples:
1. Run an application with arguments in blocking mode
KProcess::execute("app",QStringList() << "--title" <<
app->instanceName() << "--msgbox" << errorMsg.toLocal8Bit());
or
KProcess p;
p.start("app",QStringList() << "--title" << app->instanceName() <<
"--msgbox" << errorMsg.toLocal8Bit());
p.waitForFinished();
2. Start application and notify on exit
class MyClass {
KProcess p;
protected Q_SLOTS:
void handleFinished();
...
}
QObject::connect(&p, SIGNAL(finished()), &this,
SLOT(handleFinished()) );
p.start("app",QStringList() << "--title" << app->instanceName() <<
"--msgbox" << errorMsg.toLocal8Bit());
MyClass::handleFinished()
{
// handle finishing
}
3. Start application and read stdout/stderr
class MyClass {
KProcess p;
...
protected Q_SLOTS:
void printStdOut();
void printStdErr();
}
QObject::connect(&p, SIGNAL(readReadStandardOutput()), &this,
SLOT(printStdOut()) );
QObject::connect(&p, SIGNAL(readReadStandardError()), &this,
SLOT(printStderr()) );
p.start("app",QStringList() << "--title" << app->instanceName() <<
"--msgbox" << errorMsg.toLocal8Bit());
...
MyClass::printStdOut()
{
QByteArray data = p.readAllStandardOutput();
qDebug(data);
}
MyClass::printStdErr()
{
QByteArray data = p.readAllStandardError();
qDebug(data);
}
3. Start application using a shell
KProcess p
p.start(p.getShell(),QStringList() << "konsole --title" <<
app->instanceName());
Any comments or objectivies ?
BTW: This is not to fool anyone, I saw only that there were some plans
to port KProcess in the last year, but unfortunally does not come to
light and now it is real requred to fix this stuff, because the next
major windows KDE issue - kdeinit and kioslave loading are waiting for a
solution.
Ralf
More information about the Kde-windows
mailing list