Proposal: dlopening the file dialog

Lubos Lunak l.lunak at suse.cz
Fri Mar 30 07:33:49 BST 2007


On čt 29. března 2007, David Faure wrote:
> On Thursday 29 March 2007, Lubos Lunak wrote:
> > On čt 29. března 2007, Jaroslaw Staniek wrote:
> > > David Faure said the following, On 2007-03-29 20:38:
> > > > Coolo and Dirk convinced me yesterday of the following approach:
> > >
> > > [..]
> > >
> > > Hello,
> > >
> > > A quick question here: how about so called "FileDialog daemon":
> > > - by behaviour very similar to kdialog app
> > > - starting at KDE startup and then listening to DBUS requests.
> >
> >  I was about to ask the same, but if KFileDialog will be abstracted so
> > that it will be possible to load all the internals using dlopen, then I
> > expect changing the abstraction to use something else instead should be
> > doable as well, right?
>
> Hmm, only if there are no pointers in the interface.
> If the KAbstractFileWidget interface says:
>     virtual KToolBar *toolBar() const;
>     virtual KComboBox *locationEdit() const;
>     virtual KComboBox *filterWidget() const;
> then it can't be implemented using IPC....

 Of course they can, you just need to try harder :). The same applies to 
your 'extra daemon' and probably 'bad integration' from your other mail (not 
sure about the second one, what did you have in mind specifically?). Ok, 
maybe not completely, but to a sufficient level, I have some proof-of-concept 
code somewhere that can do things like 
http://ktown.kde.org/~seli/download/qtkde/scribus_gettext.png (Scribus is 
Qt-only).

 I'm mainly asking because of the external filedialog because of 
interoperability/kde3vs4compatibility/whatever ideas from Malaga. If you 
remember please CC me on the commit of the abstract interface, I'd like to 
check if there isn't some obvious problem that'd prevent this in the future 
if it ever becomes more than just theory.

> But good thing you mention it, I looked around and those are used rarely
> enough, (mostly in those rare subclasses), so they could be in libkfile
> itself and not in the interface.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz




More information about the kde-core-devel mailing list