Redefining kdelibs and kdebase

[David Johnson]

On Saturday 27 August 2005 03:30 am, Simon Hausmann wrote:

> The idea is to run the file dialog, print dialog, etc. out of
> process. 'Our' implementation of the file dialog can reside in KDE
> workspace and all that is in KDE framework is an interface to launch
> the dialog. On Unix under KDE it could just do a dbus call to kded
> and fire up the out-of-process file dialog. When running the KDE app
> under GNOME it could use the same dbus interface to fire up the GNOME
> dialog. Under Windows it'd do it like Qt: Use the windows dialog.

Is there any particular reason why Qt's method of wrapping QFileDialog 
around the native file dialog is inadequate? Maybe things have changed 
in Qt4, but aren't the win32 and Aqua file dialogs in-process? It seems 
to me that wrapping KFileDialog around the native Win32, Aqua, GTK+, 
etc, dialogs is much simpler. If KDE is the native desktop, then we run 
our own dialog.

Or is there some reason to move the file dialogs out-of-process that I 
am not aware of? 

-- 
David Johnson
___________________
http://www.usermode.org