[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] [PATCH] KPIM::Part for better integration
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2004-07-27 6:43:15
Message-ID: 200407270843.15822.hausmann () kde ! org
[Download RAW message or body]

On Monday 26 July 2004 23:47, Holger Freyther wrote:
> On Monday 26 July 2004 23:22, Tobias Koenig wrote:
> > Hi,
> >
> > during bug fixing we found some problems with interaction between the
> > components of Kontact and the framework. For this reason I implemented a
> > KPIM::Part which inherits from KParts::ReadOnlyPart and should be used
> > by all PIM applications which want to be used inside Kontact.
> >
> > The attached patch adds this new class and ports all available Kontact
> > components to it (just ignore the small changes in KAddressBook...)
> >
> > Ok for commit?
>
> Did you not use cvs diff -uN? as I seem not to see the KPIM::Part in the
> patch.
>
> I've one question concerning the usage of dynamic_cast on the dlopened
> parts with KPIM::Part. Simon do you know if this dynamic_cast work on the
> plugins could/will  fail. AFAIK and remember dynamic_cast on dlopen objects
> does not work correctly.
>
> If it doesn't work can we use qt_cast here?

dynamic_cast on objects that were created inside dlopened modules fails to 
work when the destination type info (the one you're trying to cast to) is not 
contained in a library that is shared between the opened module and the 
application/module that is trying to execute the cast. Both need to 
explicitly link against it. So casting to KPIM::Part is not a problem if the 
module that implements and instantiated the part links against libkdepim (or 
wherever the base implementation is), as well as the application/plugin that 
is trying to do the cast. Including the header file that holds the 
declaration of some FooKontactPlugin and dynamic_cast'ing on that type from 
somewhere outside the module that holds FooKontactPlugin will fail.

qt_cast strictly speaking does not have that restriction, as the 
FooClass::staticMetaObject() symbol is not weak. However if the moc generated 
code is not shared and you start adding/removing signals and therefore change 
the integer ids qt_invoke/qt_emit uses at run-time then lots of funny things 
and crashes are likely to happen.


Simon
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]