Redefining kdelibs and kdebase
Christoph Cullmann
cullmann at babylon2k.de
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?
cu
Christoph
More information about the kde-core-devel
mailing list