KProcess overhaul

Ralf Habacker ralf.habacker at freenet.de
Sat Apr 15 09:50:14 BST 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-core-devel mailing list