Reimplementing trivial apps as dcop services

[George Staikos]

On Saturday 02 April 2005 19:21, Luke Alan Sandell wrote:
> 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.

   The first time you execute it, it will be slow though.

> 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...

   No, they should die over time (unused) to avoid bloating memory.  Also 
putting them in kded will just further propagate problems with system-wide 
deadlock (ex: #103184)

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/