Reimplementing trivial apps as dcop services

Luke Alan Sandell spam at reasonsvoice.com
Sun Apr 3 02:21:03 CEST 2005


There is a variety of command-line apps which are meant mainly for use in
shell scripts and which work by calling their corresponding kdelibs
functions. We have kdialog, kcolorchooser (which should arguably be a part
of kdialog for consistency purposes) and kprinter. Since each of these must
be dynamically linked to libkdecore (and initialize all its global objects)
as well as create their own instance of KApplication, they are extremely
slow. On my 300 MHz, it takes up to 4 secs to do a simple 'kdialog --msgbox
hello'. However, I found that the 'dcop' command for invoking dcop
functions is extremely fast, and so it dawned upon me to simply create dcop
services for all these commands (which I have stated to do). For instance,
I now type 'dcop myservice dialogs messageBox hello' and this only takes
about .5 secs.

Of course, the actual command-line utilities could be rewritten as shell
scripts that call 'dcop' based on the command-line arguments passed to
them. Also, we don't want all these random dcop services sitting around in
the process list, so they should probably be integrated into kded. I was
wondering if this all makes sense, and if should I continue with it...

-Luke Sandell



More information about the Kde-optimize mailing list