Proposal: dlopening the file dialog

[David Faure]

On Thursday 29 March 2007, Jaroslaw Staniek wrote:
> A quick question here: how about so called "FileDialog daemon":
> - by behaviour very similar to kdialog app
> - starting at KDE startup and then listening to DBUS requests.
> 
> Would this be on of the fastest possible ways to display file dialogs of many 
> kinds (and some other general purpose dialogs, like fonts) or am I missing 
> something?

Faster maybe (dlopen is quite fast too), but:
- one more daemon [can't be done in kded, especially not with modal dialogs]
- bad integration into the applications [not a "real" modal dialog in terms of the
relation between the window]
- less control over the contents [can't use the Qt API to access the filter combo,
the location edit, etc. like I see many applications do]. But of course if we have
libkfile then that's the solution for this kind of use case.

> The dialog could be of course wrapped in the similar file dialog API we have 
> already, and since it is alive all the time, it could cache some data like 
> data structures or even widgets for a number of recently used directories. 
> Users usually start browsing from the same "home" or some sort of "my 
> documents" location again and again...
But we want per-application history, and view mode, and start dirs etc.

And what happens if you open a file dialog in an application, then think 
about something else, switch to another application, and then try to open
a file dialog there? Ouch.

The idea of kio_uiserver providing dialogs is very..... kde3. I got rid of all of 
them during the course of kde3 because of the problems outlined above.

Really, I find that normal widgets are much nicer than gui servers.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).