Proposal: dlopening the file dialog

[David Faure]

Coolo and Dirk convinced me yesterday of the following approach:
 keeping the KFileDialog API in libkio where it is now, but moving the implementation
(including KFileView, KFileIconView, KFileTreeView, KDirOperator, etc.) to a new library, 
which we could call libkfile for instance :), and letting KFileDialog dlopen a module that links to libkfile.

The advantages:
- making kio smaller, without all those mostly-internal classes with lots of virtual methods, 
which according to Dirk leads to many unnecessary reallocations during startup
- allowing to move out of kio the last chunk of qt3support-bound code, which would allow to finally
make kdeui and kio qt3support free. libkfile would link to kde3support for a little longer [if not forever].
I had a look at writing a KFileListView based on QListView+KDirModel and that implements 
the generic KFileView interface, but that's not compatible. KFileView inserts KFileItems itself into 
the views, while the model/view solution means letting the model update the view directly.
Could use a QListWidget instead, but it doesn't look like an efficient solution, in the long term.
Redesigning KFileView would be a very big undertaking given the number of views that use it
(KCombiView, KFilePreview, and the old views which I have locally renamed to K3FileDetailView
and K3FileIconView for this weekend).
And all those are public classes, used by e.g. kdevelop, mailody, kaffeine, kdebluetooth...
so the file dialog rewrite would affect them too.
Not much point in delaying the stability of kdelibs for that rewrite, when we can use this solution
of, well, moving the problem away :)

So those few apps would still have to link libkfile, but all other apps wouldn't have to; kio would
dlopen it for them -when- they pop up a file dialog for the first time.

==> What about the following plan?
In kio:
* KFileDialog API is moved, unchanged, to a KAbstractFileDialog interface class,
* KFileDialog derives from it, providing this API to application code (both static methods and constructor+methods) -> no code porting
* kfiledialog.cpp simply forward the calls to another KAbstractFileDialog instance,
which would be found using KLibLoader.

In a new dir, kdelibs/kfile:
* KRealFileDialog derives KAbstractFileDialog, implements it for real (the current kfiledialog code)
* KFileView and friends are here
* A lib and a module get compiled
* The lib links to kde3support for now (where K3IconView and K3ListView can finally move)

And the few apps that use KFileView are changed to link to libkfile.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).