Redefining kdelibs and kdebase

[Stephan Kulow]

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).

Greetings, Stephan

-- 
Mein Lebensmotto?
Man muss auch mal 1+1 gerade sein lassen können.