Redefining kdelibs and kdebase
david at usermode.org
Sun Aug 28 01:30:06 BST 2005
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?
More information about the kde-core-devel