On Saturday 03 September 2005 11:40, Christoph Cullmann wrote:
[...]
>
> I support this RuDi thingy for foreign apps wanting to use our framework (+
> being able to use gnome etc.) but not that native KDE apps have to use such
> stuff. RuDi is thought to be bridge for ISV's and co to be able to use
> KDE/GNOME stuff transparently without linking and to provide a stable API
> and so on, but not to be used inside the KDE software stack, or?

The concept has similar advantages also inside the KDE software stack (Imagine 
KDE 4 applications running on KDE 5), and it helps KDE application to 
integrate better in other desktop environments. Performance-wise this can 
turn out to be an advantage, centralizing services can improve responsiveness 
and reduce memory consumption. The filedialog would e.g. simply be there and 
can be shown in no time, whereas today every application linking to libkfile 
has to first instantiate and initialize it.

If we are going to do RuDi properly, we have to make it a 1st class citizen in 
the KDE world, meaning we would have to use it ourselves. In order to see 
that this is feasible, we must first make a prototype that proves this. My 
feeling is that the concept has no chance for broad acceptance if it remains 
an additional bridge/bludge only. 

Decoupling applications from desktop services out-of-process is not a new 
thing, most sytems do that. KDE itself does it already for several services, 
with some prominent omissions like the mentioned file dialog.

Matthias