Redefining kdelibs and kdebase
coolo at kde.org
Sat Aug 27 14:06:23 BST 2005
Am Samstag 27 August 2005 14:36 schrieb Anders Lund:
> On Saturday 27 August 2005 14:26, Clarence Dang wrote:
> > the file view is inconsistent with Konqueror's - as is ark's,
> > standalone KFind's, Kate's file lister,...
> In most places KDirOperator is used (the file dialog, kate and any app that
> copied kates directory view, and more). If konquerors view can be used with
> a comparable speed and with a resonable set of features, it should be
> (moved and) used by that class.
So we have two different trends here? One side (let's name them Qt
maintainers) support KDE's future as least common dominator that Qt can
easily replace or use. And another side sees rather more connection between
konqueror and the file dialogs? Did I summarize correctly?
I find it hard to believe that we can hook the KDE file dialog into Windows
applications not written for KDE. So without that, you would always have
KDE applications use another file dialog than any other application on
windows. Not sure that's appealing - even if the KDE file dialog might have
more options. On the other hand, not allowing customizing or embedding the
file dialog because it might break for use on non-KDE desktop shells sounds
broken as well. So what do we do here?
I suggest we leave KDE file dialog in kdelibs but in a special library
(libkfile sound good, no? :) allowing custom use as currently and
applications using only the static functions to get a file name will use the
out of process file dialog pre forked without needing to link to libkfile
(as the static functions would stay in libkio).
Man muss auch mal 1+1 gerade sein lassen können.
More information about the kde-core-devel