klingens at kde.org
Thu Sep 12 19:24:17 BST 2002
On Thursday 12 September 2002 17:50, Oswald Buddenhagen wrote:
> On Thu, Sep 12, 2002 at 05:37:42PM +0200, Martijn Klingens wrote:
> > Would something like this help? Now you can install a crash handler
> > before the KApp constructor yourself.
> hardly in this case ... i want it explicitly 0 (which is SIG_DFL).
Ah, I see. Basically you need a static bool KCrash::isSet(), which returns
true when an explicit call to set the crash handler has been made, right?
> i think this should be made a global flag like the kde_have_kipc hack
> which was created for kdm as well.
That can be an alternative solution indeed.
> the problem is, that kapp basically pulls in everything kdelibs offers
> and you have no way to get rid of it. this is convenient in most cases,
> but it was a problem for kdm many times already. also, it implies that
> the most trivial application has to link against quite some libs. maybe,
> as hook system should be introduced, which allows libs to add their
> features to kapp if they are linked. i'm talking about dcop in
> particular, but that can be applied to other parts as well, i guess.
Hmm, nice idea, but how can you do that? Kopete can call methods in its
plugins because they are explicitly dlopened, but can you make a shared lib
auto-execute some code when it's opened at application startup? And if so,
can you assume some code has been run before or should that code be
(Not to mention that it would change KApplication's semantics in a way that
can hardly be done right without breaking existing apps. In other words, not
before KDE 4.)
More information about the kde-core-devel