[file dialogs] Re: Redefining kdelibs and kdebase

[Waldo Bastian]

On Sunday 04 September 2005 22:55, Waldo Bastian wrote:
> 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".

What would also be interesting is to see if it's possible to add support for 
uploading/downloading of non-file URLs. The uploading part might be tricky, 
especially if the application isn't written with such a thing in mind.

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/01559a84/attachment.sig>