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