Bug in KAction::initPrivate

[Simon Hausmann]

On Thu, Sep 26, 2002 at 01:07:19PM +0200, Michael Brade wrote:
> > I'm not exactly sure how Martijn got the double connect though. Did
> > the object name of the action happen to be like foo{42} ? (it's the
> > only explanation I can come up with)
> As it seems to me, the following causes a double connection:
>   connect( this, SIGNAL(activated()), recv, SLOT(blah()) );
>   connect( this, SIGNAL(activated(int)), recv, SLOT(blah()) );

Ahh, stupid me. You're right, I forgot about this possible mapping.
Ok, good, last missing piece of the puzzle found :)

> However, I tried to remove the recv and the slot in KListAction to not pass 
> them to the KAction constructor. Still, I got a warning about a conflict?! 
> Then I tried to disconnect() that signal which didn't work either. That was 
> the point when I gave up...
> 
> Here's the exact message I get every time:
> QMetaObject::findSignal:KListAction: Conflict with KAction::activated(int)
> 
> Ohh.. When just adding the removed connect I get:
> QMetaObject::findSignal:KSelectAction: Conflict with KAction::activated(int)
> QMetaObject::findSignal:KListAction: Conflict with KAction::activated(int)
> 
> Hmm. When disconnecting or removing recv in addition to the connect I got only 
> the KListAction conflict... maybe it _did_ work? But why this conflict and 
> what does it mean?

That's a new feature in Qt3.1, it warns about braindamaged signal
declarations. The thing is that KAction declares activated( int )
and KListAction as well. This makes few sense :)

So that's a third problem ;-) . It will get fixed if we revert the
name-magic{42} or if someone removes the activated( int ) signal
declaration in KListAction (these two fixes are mutually exclusive
:)

Simon