kdebase/kdm/chooser

[Martijn Klingens]

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 
completely self-contained?

(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.)

Martijn