Reimplementing trivial apps as dcop services

[Lubos Lunak]

On Monday 04 of April 2005 16:44, George Staikos wrote:
> 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.

 Not if it's in kded. And even if it's slow for the first time, it's still 
only the first time.

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

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

 Caused by improperly coded kded modules. At least I believe so. I think that 
kded modules that open a new dialog and return back to the event loop instead 
of re-entering shouldn't cause any problems.

> > I was wondering if this all makes sense, and if should I continue with
> > it...

 It makes sense (at least to try it ;) ). And there's one more possible use of 
it which I'm not sure you're aware of - for use from other toolkits. E.g. 
OOo-KDE currently uses kdialog (in fact a fork of it) for its file open 
dialog, but it could use such kded module instead.

 Also, in SUSE9.3 some Qt applications can use KDE dialogs, implemented using 
such kded module and by patching Qt. I haven't had that much time for it yet, 
and there are still some problems, some of them quite complicated to handle, 
but if it gets really usable that'd mean OOo, Qt-only apps or any other apps 
could have KDE features like file dialogs when running in KDE, without 
linking against KDE. At least TT should be interested in Qt-only apps looking 
more like KDE apps.

 If you're interested in helping with it, or at least having a look, I could 
put the sources somewhere.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/