Redefining kdelibs and kdebase

Christoph Cullmann cullmann at
Mon Aug 29 09:08:26 BST 2005

On Monday 29 August 2005 00:07, Simon Hausmann wrote:
> > 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).
> I think that's an excellent compromise. Noone in KDE would be crippled or
> loose flexibility, non-KDE apps could fire up our dialog (with an interface
> a bit richer than just what kdialog's commandline interface offers) and KDE
> apps may in the common case get a chance of firing up a 'native' dialog on
> other platforms.
If we can fix the problems ths out-of-process stuff carries on, like that the 
window manager needs to know to which toplevel window the dialog belongs, 
that it is modal for this, that the password infos are shared and all it 
sounds like a good idea to have, for example to allow konsole use kfiledialog 
without linking just for the rare usage.
But all this just not requires that much changes like you wanted, as I still 
think, if we want ISV's to use kde platform even on win & mac, not waste time 
with this stuff and better get whole kdelibs ported, considering how much of 
this even work atm on windows (thought hacky), this should turn out to be 
solved much faster, is that much still missing beside the whole kio/kconfig 
stuff there?


More information about the kde-core-devel mailing list