Bug in KAction::initPrivate

[Andreas Beckermann]

On Friday 27 September 2002 10:59, Simon Hausmann wrote:
> > Well - *if* you do it *please* do it asap. I'll have to change boson's
> > code, too or I'll have to tell users to use KDE >= 3.0.1 but <= 3.1 for
> > boson 0.7.
>
> Ok, I'll make the change this weekend. I can make a patch for boson
> (you're talking about the code in the SF repository, right?) if you
> want, so that no work is invovled from your side.

No problem - I'll do it myself.

> Do you know of any code in the KDE CVS repository using the feature?
> A grep in kdegames didn't reveal anything to me -- but I might have
> missed something.

Hmm I though't I had used it somewhere in kdegames, but I cannot find it. 
Maybe I've never committed the patch. Ok, so it's less work :)

> Opinions differ :) BTW, in the second case you don't need the
> special action names anymore :)

Yeah, but I like to keep the option to put it into a menu one day. Or a 
toolbar.

> What makes me think the second example is more readable is because I
> for one associate the activated() signal with kaction (consistent
> and exchangable with QAction, btw) , and seeing there is
> QSignalMapper involved I immediately know that this is about mapping
> signal emissions from multiple objects to one slot. Spotting the
> setMapping calls the binding to the argument is IMHO more obvious
> than finding it in a QString( "blah_{%1}" ).arg( i ) call, at a
> place I seldom look at :)
>
> (but is probably because I don't like constructor calls with tons of
> arugments but prefer smaller ones followed by obvious setFoo calls,
> where you immediately see what the code is about, instead of
> requiring to look in the class doc to check what the 5th argument
> was about again)

For me the first solution is just a short look at the loop + creation of 
KAction objects and it's pretty clear whats going on. The second solution is 
an additional look at QSignalMapper documentation...

> Simon

CU
Andi