[file dialogs] Re: Redefining kdelibs and kdebase

[Waldo Bastian]

On Sunday 04 September 2005 22:51, Matthias Ettrich wrote:
> 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.

A good start would be to go over SVN and check what kind of modifications are 
being done to the filedialog. I suspect that the main ones are "previews" and 
"encoding selection".

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050904/4545597c/attachment.sig>